Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Firebase vs. Couchbase as Server Side: Differences That Matter

DZone's Guide to

Firebase vs. Couchbase as Server Side: Differences That Matter

Couchbase Mobile Database is perfect for large-scale projects where the server side operates with the big data amount. Firebase Real-Time Database is good for smaller projects.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

As soon as Google released Firebase, a platform for a mobile application development, I could not wait to test it with real projects. Firebase was announced as a multifunctional platform with an abundance of tools for the implementation of different application features for data analysis, storage, hosting, etc. The possibility to exchange data in real-time was the most intriguing aspect because this is the most common requirement for mobile applications right now. I am a senior Android developer on a mobile team. We used to apply Couchbase to implement real-time sync in our mobile projects before Firebase was launched.

Certainly, there are a lot of other mobile platforms that exist for the creation of mobile applications. I can list HP Cloud, Heroku, Google Cloud Platform, Amazon Web Services, Microsoft Azure, Rackspace Cloud, Couchbase Mobile, Firebase, and many others. While working on our customers’ projects, our mobile development team has become familiar with a few of them: Couchbase Mobile Database and Firebase Real-Time Database. In this article, I am going to outline advantages and disadvantages of the above-mentioned platforms. A brief look under the hood and a summary of each technology will be a good starting point.

Couchbase Mobile

Couchbase Mobile is a platform for building mobile apps with a NoSQL database that stores documents in JSON. It is good for background synchronization and security access for all clients. It contains a Couchbase Server, Sync Gateway, and Couchbase Light.

Couchbase Server is intended for the management and storage of data as JSON documents. It is capable of scaling up to terabytes of data and storing billions of records.

Couchbase Light is a database for a mobile device; it is lightweight and embedded.

Sync Gateway synchronizes the Couchbase Server and embedded databases. It has a conflict resolution feature and ensures the security of the connection between the server and the embedded database.

Moreover, data processing is maintained with built-in enterprise security-level and comprises user authentication, a user, and role-based data read/write access control, secure transport over TLS, and 256-bit AES full database encryption.

Our expertise with Couchbase is broad enough to know all its pains, pitfalls, and traps. Speaking personally, it was difficult for me to start developing with Couchbase Mobile. I had to overcome several challenges.

  1. It is not a relational database. A developer should always remember this and treat a document as a data unit.

  2. There is no query with the required criteria. A developer should make a view and add data to it first. It is similar to indexing tables in a relational DB. The next step for data retrieval is to request this view using filters by keys.

  3. To initialize the Couchbase View for the first time is a long procedure. It may influence the UI, and that is why a developer should keep UI unlocked until this process is finished.

At last, cloud services are not available for Couchbase Mobile (CM). You should download and install the Couchbase Server and Sync Gateway from the very beginning.

Quickly processing queries is the reason for a developer to create the views. In addition, working with views allows flexible data modeling. A developer can add different types of data entities into one view and then request it with a single query.

Synchronization

A server-hosted Sync Gateway helps a developer follow the revisions in every document made on the client’s side. Such synchronization allows a developer to monitor the revisions, which is essential for document management and for security. A developer can add access rules, edit fields, or add some content to the document. This is an opportunity to enhance the security level of the app by hiding some logic from the client.

Security

CM allows setting security restrictions with the help of users, roles, and channels. We all get used to users and roles. They are standard and well-known, while channels are the CM’s unique functionality. When you combine some entities into groups for some reasons, they became channels. A developer can filter these channels, establish the access rules for them, e.g. restrict some users from viewing specific channels. In addition, with the help of channel data synchronization for mobile, traffic can be confined and minimized.

Conflict Resolution

When different users work with one document at the same time, it may cause a conflict with revisions. To avoid such a conflict, Couchbase Mobile stores the document’s revisions, and in the case, there is a conflict, it restores the version with the latest revision automatically. Opposite to the default solution, a developer can add a custom algorithm for conflict resolution: applying the appropriate revision and deleting others or combining several revisions into the final document.

To conclude, Couchbase Mobile is not an easy thing for a beginner, but the more you learn, the more benefits your projects gain due to flawless server-client synchronization and manageable access to data.

Firebase

Firebase is a cloud-hosted tool to build an application which requires supporting a number of functions such as data storage, analytic reports, cloud messaging, hosting, notifications, remote configurations, application indexing, and dynamic links. This functionality is mainly provided for free. Still, Firebase has limits devoted to the amount of data for storage and transmission.

Here, I will write about Real-Time Database as a part of the Firebase service.

Firebase Real-Time Database is a NoSQL database with cloud hosting, JSON-object data storing, and synchronization among all clients. In addition, it assures offline data availability as a result of data caching. The mentioned options were key reasons for us to try Firebase and compare it with the Couchbase-based solutions.

Firebase requires a registration to begin using the platform; then, a developer should create an application. Firebase Console is a management tool to assist with the application creation. There is a detailed manual combined with an easy-to-use UI to guide a developer through the process. Adding a property file and SDK to the project is the final preparational step. Done. A developer can use Firebase — no more adjustments expected, no servers or services required.

Firebase Real-Time Database (FRD) is a non-relational database similar to Couchbase Mobile. However, FRD stores data as one JSON object, and is different from Couchbase’s JSON format. In FRD, entities will be organized into a model tree. Here is the sample:

{
  "users" : {
    "-UserId1" : {
      “userName” : “user-111”,
      "registrationDate" : 1479924199695,
    },
    "-UserId2" : {
      “userName” : “user-222”,
      "registrationDate" : 1479924199695,
    }
  },
  "posts" : {
    "-PostId1" : {
      "authorId":"-UserId1",
      "createdDate" : 1480092667004
      "title" : "Post 1"
    },
    "-PostId2" : {
      "authorId":"-UserId2",
      "createdDate" : 1483492667344,
      "title" : "Post 2"
    }
  }
}

At first glance, a tree structure is more convenient to use, but it may be a problem when you move further, e.g. try to get a list of entities filtered by different fields or several filters. Well, it is not an issue for small-scale projects, whereas medium or large projects can really suffer from the lack of multiple conditions query processing. This can be a reason to switch from FRD to another platform.

The second thing is that you do not have a server-side logic as you normally have. Let's explain what I mean. If you need some special logic for some actions that you are not able to move to the clients because of security reasons, for example, you will need to invent something. Literally. In last Firebase versions, they added Cloud Functions release version 1.0. Besides, relying on our experience, it is far from everything that you are able to do their help. So, you will need some additional API, which might create a confusion in a clients’ code.

The other thing is that it is a commercial service. And you can reach free limits really fast — especially when there are data storage and data transmissions (traffic). Forgot to cache images in your app? Got it. You will reach free limits with 10-15 users per day in your app. Even during a testing phase, your testers may create more traffic than allowed for the free account. That means that you may need to pay for a service even on development phase.

At last, you are not able to close the infrastructure on Intranet. So, if you are a bank or government institution and you need to have an Intranet infrastructure, obviously, Firebase could not be your choice.

Synchronization

There is one more thing in CM and FRD that differs is the synchronization of data. In CM, all the data is arranged into channels, and a user’s public data that he has access to is synchronized on a mobile. Actually, a client-side becomes a replica of the server unless a developer adds some rules and restrictions. On the contrary, FRD stores the local cache on the device that is updated at the entity level. The selected entities can be refreshed by a request, as well. It means that in FRD the described solutions allow access to local data without a constant connection to the server.

This is the crucial difference. Taking a social application as an example, the CM will load the entire list of posts to display them on the client side, and if you don’t want it to do so, you should write some extra code to get the desired result — whereas FRD can limit the amount of data required for a refresh and download the ten most recent posts for an initial screen.

Security

User authorization along with FRD security rules provides the means to configure security restrictions in FRD. Any time the data is read or written, FRD applies the security rules. Thus, a developer can add the rule to restrict a user’s rights, enabling only the owner to write or read the entity. It can be written to the Firebase Console as follows:

{
  "rules": {
    "profiles": {
         "$userId": {
           ".read": "auth != null && auth.uid == $userId",
           ".write": "auth != null && auth.uid == $userId"
        }
    }
}

Similar to CD channels, FRD allows setting access levels for data via security rules. This differs from CD, where channels that are just keys or labels. Security rules in FRD are expressions and provide more space and flexibility for the developer.

Conflict Resolution

FRD resolves conflicts via transactions. Each update of the entity can cause a conflict, FRD has a Transaction Operation tool to prevent it. For instance, a modification of the count value of the entity can result in a conflict. To prevent it, the modification should be settled as a transaction. Furthermore, this transaction can be performed simultaneously on several client-sides. As we described above, CM has different options for conflict resolution. A developer should mind the difference when making the decision on the DB for a project.

Conclusion

Pros

Couchbase Mobile Database

Firebase Real-Time Database

  • Real-time synchronization
  • All the data available offline
  • Security of data read/ write operations
  • Data indexes
  • Stability
  • No data restrictions
  • Open-source service
  • The conflict resolution can be customized
  • Some logic can be hidden from a client
  • Real-time synchronization
  • Offline work
  • Security of data read/write operations
  • Free for small projects
  • Easy to start
  • It synchronizes only data that a user requests


Cons:

Couchbase Mobile Database

Firebase Real-Time Database

  • Hard to start
  • Application server is needed
  • Hard to limit the amount of synchronized data
  • Constant speed inspection and query optimization are required
  • No possibility to run a complicated query within the database
  • No reduce function
  • Data amount restrictions exist
  • Commercial platform
  • No customization of the conflict resolution process

To sum things up, the Couchbase Mobile Database is a perfect platform that fits large-scale projects where the server side operates with the big data amount, having complex data processing and the same minor chunks of data on the device. Nevertheless, there is an exception for the projects that host a huge amount of public data accessible by any user from the client side: a developer should choose another service.

Firebase Real-Time Database instead is good for small-sized and medium projects, where there is no need for complicated data operating and possessing simple features.

Do you pay to use your database? What if your database paid you? Learn more with RavenDB.

Topics:
database ,couchbase ,firebase ,real-time data ,synchronization ,data security ,conflict resolution

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}