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 2

DZone's Guide to

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

Is Thin Client or Thick Client the best architecture style for your app?

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

In the first part of this blog series, we kicked things off by taking a look at the three possible categories that a typical real-time app falls into. Now, let’s start to explore the design choices for all three kinds of apps. Quick heads up before we dive deeper—the term “app” used throughout this series includes the complete stack from the server to the client.

The less logic, the smarter it gets.

We’ve heard it before and we’ll hear it again—the thick vs. thin client design choice is a pendulum that swings back and forth. It’s influenced by various software stacks promising performance, developer productivity, or user experience benefits.

At the end of the day though, the bottom line is that the ideal platform is one that doesn’t require a single excessive line in your code base.

Technology-wise, the client can be a native or HTML5 app. The technology itself doesn’t dictate whether the client should be thick or thin. Instead, that distinction is determined by where the application logic is executed, plus the session data that goes with it).

SC Diagram

When it comes to the thin client approach, the application logic lives on the server. That means there’s no duplication whatsoever. With native technologies, the client becomes the presentation layer—limited to rendering of UI widgets. The server dictates what widgets to display. With HTML, the server returns a static HTML document and the client may be a Web browser with disabled scripting. This could be a good approach for ‘CA’-oriented apps as the server is the only source of truth. (Click here for a quick refresher on the CAP—Consistency, Availability, Partition-tolerance—a theorem that we covered in Part 1.)

Flipping the coin, the thick client approach is quite the opposite. In that case, the server contains application logic exposed through an API. The client acts not only as the presentation layer but as the controller, as well, which decides what and when to ask from the server. This could be a good approach for ‘AP’-oriented apps since it allows the UX to decouple from the network latency.

In Part 3, we’ll explore the rise of the isomorphic thick client, and pose a key question you should ask yourself before you consider the framework for building your real-time app.



Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
database

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

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}