How to Choose the Right Database & Framework for your Real-Time Mobile App, Part III

In Parts I and II of this blog series, we presented three possible categories that a typical real-time mobile app falls into, and started to take a look at the design choices for all three kinds of apps. Now, let’s continue to explore some additional considerations when it comes to choosing the right database and framework for your real-time app.

The rise of the isomorphic thick client

Especially in the JavaScript realm, we’ve seen an increase in the adoption of isomorphic code design, allowing thick clients to benefit from the same programming language on both ends.

Meteor is a perfect example of an isomorphic JavaScript framework. Because of the code reuse, the client can predict the server’s response and improve perceived performance through immediate feedback to the user. It’s worth noting that as of version 1.0, Meteor is heavily tied to MongoDB, making it less suitable for apps that require an ACID database.

Thanks to frameworks like Invisible.js, Ezel and Rendr, the isomorphic trend has spread over to the NodeJS platform. These use the Backbone framework to define the application logic, which is then used on the server and client.

Want to take things one step further? Check out Derby, a framework that provides built-in operational transformation features that enable real-time collaboration. But worth noting here, as well – Derby requires MongoDB or Redis database, so again no ACID.

Thick client is clumsy

The isomorphic client code, at best, reuses parts of the application logic and business logic. Flipping the coin – at worst, it duplicates servers’ functionality and the data flows through a gray area of API infrastructure, serialization and validation.

Add to this not one, but many client devices to consider (mobile, tablet, desktop, backoffice), and the amount of overlapping code exceeds the amount of case-specific code.

Before you consider the framework for building your real-time app, step back and think about what changes more often – the app or the data? Of course it’s the data that changes all the time, so the most suitable platform for building real-time apps is the one which heart beats where the data is.

In Part IV, we’ll take a look at the database as the puppeteer, as well as an open-source protocol that allows developers to share the application view-model between the client and the server.

By | 2017-03-30T12:10:35+00:00 November 12th, 2015|Apps, Database|0 Comments

By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.