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

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

DZone's Guide to

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

Let’s continue to explore some additional considerations when it comes to choosing the right database and framework for your real-time app.

Free Resource

Learn NoSQL for free with hands-on sample code, example queries, tutorials, and more.  Brought to you in partnership with Couchbase.

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.

The Getting Started with NoSQL Guide will get you hands-on with NoSQL in minutes with no coding needed. Brought to you in partnership with Couchbase.

Topics:
database ,mobile

Published at DZone with permission of Marcin Warpechowski, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}