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).
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 – 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 III, 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.