5 promises of server-side RIA
Although frequently dismissed as a crutch for former desktop developers, server-side RIA has some serious advantages:
- Security: Client-server APIs usually aren't well designed and they are almost never audited for security issues. Server-side RIA exposes only the UI to the client, which leads to much smaller attack surface that is much better tested and much more thought about.
- IP protection: Source code is a secret kept on the server. Data cannot escape in bulk though misdesigned client-server APIs.
Dispelling misconceptions and worries
There is some existing criticism of the server-side RIA concept and some of it is actually true for Vaadin. We better learn from the soft feedback before we crash into hard feedback. Let me take the issues on one by one:
- Server RAM: I think this really depends on how the server-side framework is designed. If all session state is stored under session ID in a lightweight database, there is really no data that would have to be tracked by the RIA framework. The page can be fully regenerated from the stored session data. HTML streaming (which usually sends only HTML diffs) can be restarted by sending full page update to the client.
- Bandwidth: While there will be a bit more traffic with server-side solution, it is nowhere near demands of video streaming. There's abundance of bandwidth on both client and server that's more than sufficient for our text-only transfers.
- Latency: Just how fast can the server-side RIA be? Server-side page generator coded in Java or C# can be expected to respond in milliseconds. Database (or its cache) is located right next to the application server, so data access latencies are essentially zero. Client-side runtime is minimal and heavily optimized. So it's up to network round-trips. With websocket, we have single round-trip per interaction. Most apps are language-specific and consequently region-specific, which means negligible RTT well below 50ms. Global sites can either live with 130ms average Internet RTT or replicate themselves on every continent, yielding RTT below 50ms.
- Expressiveness: Client-side RIA is theoretically more expressive and this is also practically true in some niche scenarios. Nevertheless, server-side RIA can be extended with purpose-built client-side widgets while keeping the rest of the application on the server. It's not necessary to move whole application to the client just to get some special effect working.
- Offline use: This is a real problem, because once one gets used to the comfort of server-side environment, it is next to impossible to port the application into the restrictive client environment. Nevertheless, I believe we will eventually reach a point in history when network connectivity will be ubiquitous and as reliable as electricity. Meantime, existing connectivity is good enough to provide top service to a large majority of users. Apps that really do have to run offline can just package embedded version of the server and run it all on the client.
Vaadin is nice, but...
- It insulates me from HTML/CSS rather than embracing existing standards as presentation/layout layer. This results in weird limitations and rendering issues. Paradoxically, it forces development of custom client-side widgets in way too many ordinary scenarios.
- It creates heavy and deep DOM without good reason. This cripples client-side performance and causes styling and widget authoring headaches.
- It's a memory hog. This will limit scalability to really, really small deployments, especially when people leave inactive sessions hanging around.
- Its eventing and data binding mechanisms encourage programmers to leave memory leaks everywhere.
- Binding and templating is verbose and very unproductive. We need something concise and heavily automated.
- It's big and complicated, because Vaadin is business rather than community project. Chances are that I or my employer would be pressured to pay for the non-free version.
7 principles of server-side RIA design
I don't want to give up on the idea, but I cannot use Vaadin as is. I guess I will have to come up with something of my own. Here's my plan:
- Embrace HTML/CSS: No complicated widgets. Merely enable data-driven templating of HTML. Don't mess with CSS at all. CSS should be static resource outside of the DOM.
- Assume latest technology: HTTP 2.0 instead of resource bundling. Websocket instead of AJAX and long polling. CSS3 instead of JS tricks and HTML boilerplate.
- Session hibernation: Inactive sessions are serialized into fast embedded database, then rehydrated upon user or internal event. This will enable endless scalability even with long-lived sessions.
- No boilerplate: Auto-wire data bindings and event handlers. Auto-wire dependency tracking for computed values. Auto-wire persistency for view state.
- Strong content authoring: Integrate Sass and static templating systems. Reference static templates from dynamic Java templates and vice versa. Interactive development with automatic page reload upon resource or code change.
Nice theory, but where's the code?
When I originally wrote this article, this was all just in my head. There was no actual implementation. I have since developed PushMode that incorporates most of the ideas mentioned in this article. It is still experimental, but I have developed several sites with it already. including the one you are reading now. You can give it a try. It might very well be that breath of fresh air you have been looking for.