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

In Part III of this blog series, we continued to explore some of the key considerations when choosing the right database and framework for your real-time mobile app. Now, let’s dive deeper and take a look at the database as the puppeteer, as well as Puppet itself.

Database as the puppeteer

An obvious choice is to use a RAM database. Why? Moving the application logic and the database to a single node removes network latency. But even then, the software stack builds as NodeJS + Mongo or .Net + MS SQL perform the major tasks of serialization, copying and deserializing the data. This is because the application memory is not the database memory. How can you solve that?

SC Mobile App Blog Pic 1 Enter in-memory computing. Databases like SAP HANA and Starcounter allow you to run your app code in the transactional database – resulting in 100x performance benefits compared to traditional software stacks.

When your application memory is the database memory, not a copy of it, ORM and stored procedures become a thing of the past. We call this approach “collapsing the stack.” Ditching the overhead of traditional software stacks enables developers to design completely new patterns for real-time apps.

The database can be used as the only source of truth, all the way from the data to the screen. But, only if we can bind to the current state of the data in an efficient way.

Client as a puppet

Puppet is an opSC Mobile App Blog Pic 2en-source protocol, currently implemented in Starcounter, which allows developers to share the application view-model between the client and the server.

The view-model, represented as a JSON tree, uses HTTP on the start of the client. The subsequent bidirectional changes are transmitted over HTTP or WebSocket following the JSON-Patch standard (RFC 6902).

This pattern embraces the server as the single source of truth for the view. And thus, the client can now be considered “thin” for application logic but “thick” for interactivity, which is achieved using native UI widgets or Web technologies.

In Part V, the final post of this blog series, we’ll take a look at the “think” client and wrap up this blog series by helping you assess which approach makes the most sense for you.

By | 2017-03-30T12:10:34+00:00 November 30th, 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.