Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Omnipresent Synching and Availability with Mobile Couchbase

Omnipresent Synching and Availability with Mobile Couchbase


Couchbase has launched the first iOS App with an embedded Couchbase instance. After the debut of an Android version in February and versions for WebOS and MeGoo, this means that CouchDB-enabled applications will be available on all major mobile platforms.

During the interview about the Couchbase merger with Damien Katz and James Phillip we also discussed Mobile Couchbase but decided to wait with the article until the availability was imminent.

InfoQ took the opportunity to talk (independently) to two of the people at Couchbase that drove the mobile version: CouchOne Co-Founders J. Chris Anderson (Chief-Architect Mobile) and Jan Lehnardt.

J. Chris Anderson

Chris Anderson (@jchris) is an Apache CouchDB committer and co-author of the O'Reilly book CouchDB: The Definitive Guide. He enjoys working on JavaScript CouchApps which can be peer-replicated just like any other data. Chris is obsessed with bending the physics of the web, and giving control back to users. In 2009, Chris, along with Damien Katz and Jan Lehnardt, founded CouchOne.

InfoQ: Is Mobile Couchbase having the same feature set as Couchbase Server? If not, what are the main differences?

Chris Anderson: The goal is to offer 100% compatibility, but there are some changes we are making to optimize for mobile. There are also additional features we plan to add around managing replication / synchronization.

InfoQ: What were the main constraints and difficulties in creating a NoSQL DB for mobile OSes?

Chris Anderson: This biggest constraint is a data model that is capable of offline synchronization. When my co-founder Damien Katz originally designed Apache CouchDB, he built it from the ground up for multi-user realtime offline synchronization. We are lucky that this fits so well on mobile, and especially lucky as our longtime focus on synchronizations makes us suited for mobile in a way that none of the other NoSQL databases can match.

InfoQ: What plans do you have for the future regarding mobile platforms?

Chris. The most exciting future plan is around toolkits to help web companies transition to mobile. For instance if you have all your users in the cloud, you may want some tools to help filter out the data for an individual single user, and synchronize it with their device.

Jan Lehnardt

Jan Lehnardt (@janl) has been involved with CouchDB since 2006 as a developer, consultant and evangelist. In late 2009 he co-founded CouchOne (now Couchbase) together with CouchDB inventor Damien Katz and contributor J Chris Anderson. He's the co-author of O’Reilly’s CouchDB: The Definitive Guide. He enjoys working with and on open source software. Jan is a co-organizer of the JSConf-family of conferences, most notably JSConf EU as well as the Buzzwords series of conferences focused on Big Data, Analysis, Search and Storage. He lives in Berlin, Germany.

InfoQ: What is the main goal of Mobile CouchDB ? Is it just for local app storage, as "OS service" or for synching with a remote (hosted) CouchDB service?

Jan Lehnardt: The key proposition is the synchronization. Most mobile devices come with a way to store data, but few of them sync reliably. The main goal is to enable application developers to create applications that allow a seamless operation experience without having to rely on network services. Many apps today make use of computing resources and databases in a datacenter or the cloud, but as soon as the mobile device is in a bad spot connectivity wise, the user experience suffers. Our implementation of mobile CouchDB will make apps more resilient against connectivity issues. While ubiquitous mobile broadband has been promised for a decade, now, the key to successful networked applications is low latency, and no machine on the network has a lower latency than localhost.

My favourite example (because I run into it almost every day) is Twitter on the iPhone. I'm a bit OCD when it comes to typos and wrong punctuation, so usually after sending a tweet, I will check my own timeline to see what it looks like for everybody. If I'm on the subway, I may send the tweet successfully to Twitter and then enter a no-bars zone that prohibits me to see my own timeline downloaded from Twitter. Why should I have to go over the network to read some text I just entered into my phone. This is infuriating. You can argue that this can be solved with clever clients, but if you look at this problem in general, you quickly end up that it is generally better to decouple user-interface interaction from network operations. Writing all the code to support that is daunting, so we propose CouchDB-based applications that get this working model for free.

To get there, we've got to put a few pieces in place. Luckily, the hard work is all done. Apache CouchDB (invented by our CTO Damien Katz) provides a robust multi-master synchronisation engine. It also is the foundation for our (Couchbase's) and Cloudant's CouchDB hosting that can act as an end-point for mobile devices to talk to when they are on a healthy network connection. Of course anyone can deploy CouchDB or Couchbase on their own servers, too. The next part is the packaging. We've done some prototyping work on Android and the solution is already fairly solid, although there's still a lot of room for improvement. We are also working on the iOS version, which we are even more excited about. While the Android platform allows the installation of system services (and we do so), iOS does not allow that and we have to bundle CouchDB with the native application. Technically, this is also possible with Android, and maybe eventually iOS opens up to that too. Either way though, both variants have advantages and disadvantages and we don't prescribe which one to use.

InfoQ: The Android and Web OS versions have been out there for a while. How would you describe the acceptance, existing usage and other feedback that you got?

Jan Lehnardt: We were very careful positioning the Android version. Mostly because we know it is not ready for prime-time yet. Our own Dale Harvey spent a good amount of time making it easier to build native Android apps based on CouchDB, so there's definitely good progress, but we know there are other issues we want to improve on before broadly advertising CouchDB on Android as a generic solution for everyone.

Acceptance has been great though. Android developers are genuinely excited about what happens on their favourite platform and they recognise the value proposition of a syncable data store. We managed to gather a small but passionate open source developer community around Android CouchDB that helps us getting it ready for prime-time.

As a company though, we are putting more efforts into the iOS port currently as it is harder to get right. We are going to make the iOS port of Couchbase an actual product offering while the Android port is an open source effort that we keep contributing to, but we're not looking to productise it in the near future. Of course, developer demand may change that. In addition, much of the work we are doing on iOS directly improves the Android port as well.

InfoQ: What were the main obstacles for developing CouchDB for Android and Web OS? What would make it easier to run CouchDB on these mobile platforms?

Jan Lehnardt: Both are Unix systems under the hood. This helps a lot to get initial prototypes going. But both platforms are rather young and haven't received the love other Unix and Linux distributions have when it comes to porting general-purpose software to them. It gets better though :) — On Maemo/MeeGo we can do apt-get install couchdb to get a system service running, if other OSs would support this more easily (not necessarily through apt-get, but in general through some sort of package manager) that'd go a long way, but currently, we are battling compiler edge-cases, linker flags and curious interpretations of POSIX syscalls.

InfoQ: How can I as an developer integrate with mobile CouchDB on these platforms?

Jan Lehnardt: Our Android version allows you to create a package dependency of CouchDB as a system service. On iOS you have to bundle a static library with your application. Either solution though just runs a regular CouchDB service on http://localhost:5984/ and developers can user a HTTP client library or a higher level abstraction to access CouchDB over HTTP. While it may sound that this is unnecessary overhead on a mobile device, it is very nice that an app can just use CouchDB as a data store and doesn't have to care about it being local or remote. Of course, we'll be working to make integration even tighter with native operating system services and APIs, but we'll take one step and a time and work with developers to find out what they need next.

InfoQ: Are there sample apps or developer resources to look at?

Dale Harvey has the current rundown for Android on his blog.

InfoQ: What about the iOS version? What is the current status? When can we expect it and what were the main issues you had with providing couchdb for this OS ?

Jan Lehnardt: The main issues first :) — For the longest time, Apples iOS App Submission Guidelines were preventing applications to embed custom language VMs. Although there were unofficial acceptance of say Lua, we weren't comfortable spending a lot of effort on this. Last September though, Apple updated their guidelines to make applications with an embedded CouchDB possible.

We have been working with the App Store review team to get an application accepted through the review process as we think it was important to set a precedent before giving access to the iOS version to third party developers who then in turn all run into the same basic issues. The App Store review team has been very helpful finding subtle issues that we were able to fix so far. We are also working with a small group of iOS developers to shape the iOS build into something developers will want to use. We didn't publish the app in the end because we think its quality (it's a very basic app) would overshadow the big achievement that porting CouchDB and all dependencies to iOS is.

InfoQ: Are there already app developers that plan to integrate with mobile Couchdb on the iPhone, how would an integration in a app look like?

Jan Lehnardt: There are a number of iPhone and iPad applications that use CouchDB on the server for additional storage and communication. Others are excited about it for the same reasons we are: more usable applications despite any connectivity issues. But we've played this rather low-key so far as we don't want to raise expectations until we have anything sensible to show. I'm certain, once we are actively trying to reach iOS developers on a broader scale, they'll be interested.

InfoQ: What are the main differences of the infrastructure needed to run CouchDB on the mobile OSes?

Jan Lehnardt: Use-cases define infrastructure. A single user on an iPhone that occasionally syncs to a data centre is different from a CouchDB in a data centre that has millions of iPhones replicating to it. More concurrent clients need more CPU, RAM and disk I/O obviously, but CouchDB is capable of making clever use of what is there, regardless of the scale.

Funny aside, my iPhone is about as powerful as a server from a few years ago and is capable of sustaining an impressive load, even though real apps will never exercise that.

InfoQ: Does each app run its own CouchDB instance? Or is there one system-wide? What are the communcation protocols used? Does CouchDB open HTTP ports so that also outside clients can also connect to the mobile CouchDB running on the device? What about security at these access points? Can other running apps also access the mobile CouchDB instance?

Jan Lehnardt: As I outlined earlier, both ways, embedding CouchDB in the application and using it as a system service are feasible, but it can depend on the platform as to what you can do. On iOS, there are no system services. Also, just as a repeat, the primary communication protocol is HTTP, even on the mobile device. While not theoretically optimal, we haven't found major issues with that yet. But we'll explore other options as their need arises.

For security, CouchDB has a comprehensive user and permission system as well as support for connections over SSL. Most security scenarios are covered with that.

If set up correctly, CouchDB can be made available to other devices, think bonjour-based discovery and replication based file sync for example, but that would be up to the application developer.

InfoQ: What about a cross device scenario ? I have the same or same kind of apps running on different mobile OSes, how easy is it for them all to stay in sync with a single dataset?

Jan Lehnardt: CouchDB's synchronisation is not dependent on the operating system it runs on. An Android app can sync with an iPhone, both can sync with a server or even desktop machines — CouchDB doesn't care.

InfoQ: Did you implement special means to take care of low power, cpu and space consumption on the mobile devices?

Jan Lehnardt: CouchDB is very memory friendly by default, so it is already competitive at runtime, but that doesn't mean we can't do better. We already know a few CPU-heavy things we can disable for the mobile version, but we haven't done that yet. The bigger issue is disk space we use and minifying all of CouchDB's dependencies to not include anything we don't need. We managed to get all this smaller than regular server installs, but it is not as small as it could be, so this is something we'll be continuing to work on.

InfoQ: Does Couchbase plan to develop their own applications using CouchDB on those mobile devices?

Jan Lehnardt: To understand the model better ourselves and to teach others how to use it, we have and will be writing small demo apps and in-house apps.

Many thanks to both of you for your time and the depth of your answers.

Download the Mobile Couchbase iOS Beta, watch the GitHub project or join the Mobile Couchbase Google Group. There is also a O'Reilly Webcast about CouchDB on Android.

About the Author

Michael Hunger has been an InfoQ editor for several years. He's currently focusing on topics like NoSQL, Software Craftsmanship and languages. Michael is currently working with Neo Technology on the Neo4j Graph Database and otherwise enjoys programming, learning, speaking and writing. The other half of his life is dedicated to his family of five, his own coffee-book-shop and lots of tinkering.



Rate this Article