This post is also available in: Portuguese (Brazil)
Which option for data storage to take for the next app ? CoreData, Sqlite, Sqlite with some ORM flavor, or maybe some cross-platform C based implementation, BerkleyDB, LevelDB, etc, or Couchbase Lite?
Or should you go for SaaS into something like Parse that will handle offline and sync for us?
While using SaaS is a great deal for many situations (Firebase, Parse, etc), its still generally proprietary and what I call a “lock-in”. Since data is at the heart of any application, I’d give a lot of thought before handing such responsibility to one specific vendor, specially if it uses a proprietary interface.
Last time I tried a database SaaS, my project’s code became highly dependent on their libraries, and when I wanted something a bit more customised such as having my own domain for login/registration, the prices for higher volume plus the fact that the data wouldn’t be under my control simply turned me off. Sure they have free plans for a certain number of requests, but what happens when your project succeeds ? You are ‘married’ to their solution and will have to pay the price they ask for. Open source to the rescue!
If you’re of the same opinion, there is one cross-platform, all open source solution, that shines when coming to solving these two very hard problems that faces most application developers, while still letting us in control:
- Data Storage or Persistence
- Data Synchronisation between computers
And that is, Couchbase Lite.
1st – Data storage or persistence, as old as computing itself, is crucial if not essential to any application. At some point, we need to think on how to ‘convert’ a real-life problem to some storage layer. So the main question here is:
Why working with Couchbase Lite can be better than, say, Core Data (iOS), or even sqlite?
Simply put: no more data migration headaches.
When the concept of a schema-less storage is brought inline with Objective Oriented programming, something really cool happen: you reduce the concern of how things shall be structured, and instead focus on the problem itself. At least on my experience, this drastically increased productivity because we can almost forget about the storage layer entirely when dealing with local data.
Couchbase Lite is a JSON-based database for mobile devices: that means, the storage itself does not enforce a specific structure on your data, the application developer is to do that when its sensible to. This automatically solves the data-migration headaches that happens when you need to keep things working while changes to your data’s ‘fields’ are needed. And this is just one aspect of how a schema-less storage reduces development trouble.
Why this matters?
The biggest win here is that one can simply write their programs as usual, and freely/easily define which properties of an object shall be stored. It is somehow comparable to what an ORM API (Object-Relation Mapping) system does for relational databases, but without the difficulties caused by the object-relational impedance mismatch. That is, without the problems surrounding matching an object system to a relational database.
If you ever struggled with Alter Tables, Joins and data scheme migrations, you might have an idea of how much these problems sucks big times.
Having an ORM-like storage system to use, without the disadvantages of it, should be enough of a reason for you to drop ancient tools and start using Couchbase Lite. Enough said, let’s see how this is matched with the second problem, that of data synchronisation:
2- Data Synchronisation between computers
So you’ve build your beautiful REST-API, started using your app, and bang! connection error. For whatever reason (you’re inside a train, or in a distant end-of-the world village, etc), suddenly you’re faced with a very old problem: you just don’t have the needed data, and while until now it didn’t matter what database you had under that pretty rest api, now a beast showed its face.
Depending on how important it is for your app to function offline, you start crafting a solution which syncs local data to a server and back. And then: you either give-up because its too hard, or you spend the next thousand of hours on something that apparently your customer is not even aware of.
I personally faced this problem a few years back when I was programming a CRM and production management solution in PHP for my dad’s coffee production in Minas Gerais (Brazil). Suddenly I realised many times my father would be ‘on the field’ selling coffee, and there was no way of having an internet connection while on the go, so he could not immediately register sales or add new customers to the system.
But back then I was around 17 years old, and programming alone, I knew I had to postpone this if I wanted to finish the system before my school vacation was over. Fast forward about 10 years later, and now you have a framework to do this for you.
No other system out there matches these two essential components so well: easy data storage and easy data synchronisation.
By combining Couchbase Lite (the local NoSQL database) with Couchbase’s server components, the sync process becomes the default data exchange method and therefore isn’t prone to network failures.
I would not see this as a “startup” tool or prototype project either: because it does scale. Couchbase Sync gateway (the glue between client and Couchbase Server) is written in Go and takes advantages of its high-concurrency model to serve many users and handle a high number of connections per node. Couchbase Server itself is as well ready for big data and is used by big companies such as LinkedIn.
So before you think: “Well the server database does not matter, I’ll just pick any and through a REST API in front of it anyway”, remember what happens when the connection goes out… then you might reconsider Couchbase Server as well.
I’m sorry Couchbase pals, but I couldn’t finish this post without mentioning this. What are the down-sides one needs to consider when going for Couchbase then?
First, well yes, there is a learning curve. But once you’ve learned the basics its gets easier and you’ll save time in the next projects as well with maintenance.
Second, while storying data is extremely easy, querying it can be seen as a bit harder when starting in Couchbase Lite than say, sqlite. But this is changing rapidly, a SQL query-like language for Couchbase Server is already available (called N1QL) which makes querying in the server as easy as with SQL databases (I’ve seen their demo in London’s Couchbase Live Europe 2015 and it’s really good stuff). Similarly, Couchbase Lite is to continuously roll out improvements to make querying more intuitive (in iOS currently using NSPredicate).
My opinion is that Couchbase Mobile will be a standard tool in every dev’s toolbox soon. If you want to be ahead of the curve and start learning more about it, go ahead open XCode and follow the next tutorial to learn more: Beginning with Couchbase Mobile on iOS.
If you have any other questions, comments, please write us a message telling us your experiences!