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. With proper API design (properties as methods, override instead of set, mostly computed stateless properties, list and template virtualization), server-side templates will cost very little per instance. Perhaps 1KB to 100KB per session depending on page complexity. With 100KB/session, we can store 1,000 active sessions in 100MB of RAM and 100,000 inactive sessions in 10GB of disk space.
- 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? Our compiled in-memory templates can be expected to respond in milliseconds. 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.
- Off-line use: This is 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.
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 the huge $300-500/hr support fees someday.
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.
- Templates as classes: Method render() produces HTML fragment. Method template() expands high-level template. Properties are methods returning constants, which can be easily overridden in an anonymous subclass. Data binding is merely non-constant property override. Events are empty virtual methods that templates can override.
- 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?
The tricky thing is that I am now busy doing something big that already has plenty of hard requirements. It's difficult to fulfill all those requirements with new framework. It would be much better to try it out on something smaller first. I think I won't be porting existing apps to the platform in the coming months.
I have a couple smaller projects that might benefit from exactly this kind of rapid development environment. I'll see whether I can deploy it there.
Then there's the question of how to publish it. Frameworks for developers are generally opensource and there's non-zero chance that I get contributors who will share the cost of development with me. On the other hand, I have this sensation that I am building cathedral, not bazaar. Commercial release might be more appropriate. I will have to decide this one later.