The mobile technology Couchbase announces today marks the beginning of a transition for mobile application developers: away from the web-centric LAMP stack and toward an integrated mobile stack. With JSON Anywhere, developers are free to concentrate on creating value for users, rather than writing reams of code dedicated to pushing data between devices and the cloud. Our engineers have been focussing on developer experience from the beginning of this project, so there are a lot of details that should make you happy, from social login support to live data binding for iOS’s UITableView, but the two aspects that will have the biggest impact on productivity are the flexibility of JSON schemas, and the seamless sync of JSON with other devices and the backend database.
Like many developers, I was first drawn to NoSQL for the flexibility of JSON as a database format. Because you can add new fields to your documents at any time, application developers are never left waiting for a database migration. There’s been plenty said about using JSON with agile development practices, so I won’t repeat it here. What’s important about Couchbase Lite is that it brings the power and flexibility of JSON to mobile.
JSON is particularly valuable for mobile applications, because you often have to deal with a mixture of users, some running older versions of your software, and others with the latest upgrade. Using JSON, most code will ignore “extra” fields it doesn’t use. As users upgrade to a newer version of your app, they can continue to interact with those who are still running an older version. Fields used by the new version of the app will simply be ignored by the old version. This allows your users to upgrade at their own pace, instead of forcing users to stop what they are doing and upgrade right away. While it’s possible to support rolling upgrades with a traditional architecture, it would require extra work from your server development team, instead of being a natural consequence of using a flexible database.
Application developers are always on the lookout for tools and techniques that can increase their productivity or allow them to build a better user experience with less code. We’ve seen these transitions in web architecture before: from ad-hoc CGI scripts to managed application servers, and from Java to languages like Ruby or JavaScript which focus on developer happiness. A transition like this will only succeed if it leads to major leaps in developer productivity, which is exactly what these new platforms promised. When Ruby on Rails was first announced, a rush of developers moved in, hoping to take advantage of a productivity arbitrage opportunity allowing them to charge clients less for the same work, and make more money doing it, than a comparable Java team.
Seamless sync offers even more productivity gains than the move from relational to JSON. With sync so simple that it’s easier to sync than to build a traditional web services backend for your mobile application, we’ll see a lot more applications giving their users access to their data across devices and operating systems. Sync has a reputation for being deeply hard to implement. You don’t have to look hard to find stories of companies that dedicated significant resources to building sync, and even after years of development, they still run into bugs and edge cases. It would hardly be fair to compare an app using Couchbase Lite to sync with Couchbase Server with Couchbase Sync Gateway, with an app that built it’s own custom sync facility. Anyone building sync from scratch is embarking on a multi-year process, and getting to “hello world” with Couchbase should only take a few minutes.
While sync is quickly becoming the new normal, most collaborative mobile apps today depend on being connected to a cloud server. So for fairness sake, we’ll compare the backend of one of our example apps with the same app using a Ruby on Rails backend. Our goal is to build a technology that is as much of a productivity leap for developers, as Rails was compared to it’s predecessors. So lets think through the differences between a JSON Anywhere app, and a traditional mobile app plus web services approach.
The source code to the backend of our Todo Lite exmaple app is contained in a single 33 line JavaScript function. It’s main responsibility is to ensure that each todo list can only be accessed by the people whom the list owner has designated as list members. It is also responsible for making sure that each task is routed to the devices that have access to the associated list. There are also a few lines of code dedicated to distributing user profiles to power the sharing UI. For a deeper discussion of a similar app, you can follow a data model tour of our example chat app.
In a traditional three-tier Rails app, you’d have models corresponding to users, lists, and tasks. You might also have a “membership” model that captures the access restrictions. But the biggest thing that characterizes the Rails style application, is that every time a user creates a task, or toggles a checkbox, or adds a new member to a todo list, the mobile application will make an HTTP request to the server. The server will then load the appropriate model objects from the database, validate the changes, and save back to the database. It then needs to notify any other mobile devices that their representation of the object is out of date so they can refresh. (Note that we haven’t even begun to account for the case where mobile devices are modifying data while they are disconnected…)
Let’s ballpark the amount of code you’d need to write to build such a Rails app. I’m leaving out the user / login stuff since that’s typically not written as custom code for the application.
- Models: task, list, membership, 10 lines each
- Controller: lists, tasks, memberships, each with GET, PUT and DELETE, 40 lines each
- No templates are needed because we’re returning JSON.
- Another 50 lines of code to handle sending refresh events to any listening clients.
So the grand total is about 200 lines of custom Ruby on Rails code required to build a bare-bones todo list application. This is almost an order of magnitude more code than the Couchbase Sync Gateway function used by Todo Lite. Which would you rather write and maintain? With the Couchbase stack, not only do you get offline capable sync, but your backend requires much less code, freeing you to spend your time creating value where it matters, in your users hands.
