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
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.