Over a million developers have joined DZone.

How to Choose the Right Database and Framework for Your Real-Time Mobile App – Part 4

DZone 's Guide to

How to Choose the Right Database and Framework for Your Real-Time Mobile App – Part 4

In the fourth part of our series on choosing the proper database and framework for your mobile app we'll look at RAM databases: pros, cons, and concessions.

· Mobile Zone ·
Free Resource

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.

mobile ,database ,framework

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}