In Part IV of this blog series, we dove deeper into the database as the puppeteer, as well as Puppet itself. In this final post, we’ll take a quick look at the “think” client and wrap things by helping you assess which approach makes the most sense for you when choosing the right database and framework for your real-time app.
The “think” client
How can a client be reduced to display server-controlled data yet maintain the richness of the UI?
With Web technologies, a new approach is to use React library to render HTML5 views, populated with data using Facebook’s Flux pattern. It’s possible to dispatch the data directly from the server via WebSockets, as presented in this blog post.
Submitted to W3C by Google, this new emerging standard allows developers to use custom HTML tags, composed using standard browser technologies such as DOM and CSS.
With the Polymer framework and hundreds of Web Components already available online, HTML code can be reduced to a declarative template for the two-way data binding connection, with the server using a minimalist protocol such as Puppet.
So which approach is right for you?
The software stacks discussed in this blog series bridge the server and client. The construction might be more reminiscent of:
- A movable bridge with application logic on both ends – thick client
- An elevated highway from the application logic to the presentation layer – thin client
The thin client approach on a stack such as Puppet/Starcounter works well wherever an ACID database or exceptional time to market is needed. This approach is appropriate for transactional systems such as mobile banking, ERP and other B2B use cases where performance and security are important.
Door number three? A hybrid approach. A thick client can provide a rich and responsive experience that enables offline work, while the Puppet approach enables the transactional part of the operations.
Looking ahead, further advancements will allow developers to run replicated copies of RAM databases directly on the mobile device, creating the transactional power of in-memory computing regardless of network availability.