Robert's blog
Robert Važan

Server-side RIA framework

RIA doesn't need to be client-side. Server-side, if properly implemented, actually offers huge advantages to developers and end users alike.

Web page reloads are so retro, so 90's. While acceptable for content, they are serious hindrance for apps. Especially when you are trying to migrate users from desktop apps or compete with new smartphone apps. RIA (rich internet application) comes to the rescue. Partially so. It can indeed deliver interactivity of native apps, but it comes at the cost of low productivity and all that javascript results in poor performance on low-end devices.

There's another concept that I believe to be the future of the web: server-side RIAs. The trick is that websocket allows server-side scripts to remotely control the client. Javascript is no longer needed for interactivity, at least not much of it. I've asked on StackOverflow for state-of-the-art implementations of server-side RIA and, after a week of weeding out irrelevant answers, someone mentioned Vaadin. I will get back to that one in a moment, but let me first restate why am I looking for something server-side.

5 promises of server-side RIA

Although frequently dismissed as a crutch for former desktop developers, server-side RIA has some serious advantages:

  1. Productivity: No application logic duplication on client and server. No client-server API design. No client-side debugging. Everything is tightly integrated in cozy environment of the application server. Since we are no longer tied to javascript, we can select more productive development platform with as many libraries as we wish while maintaining perfect compatibility on the client.
  2. 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.
  3. Compatibility: Client-side RIAs stress the client with heavy javascript libraries that ask for a lot of advanced javascript APIs. This results in sluggish performance on low-power devices or outright failure to display the page. Client-side RIAs are often so slow as to bring down desktop browsers. Server-side RIA has minimum client requirements and thus greatest compatibility as well as performance on low-end devices.
  4. Initial load time: Since server-side RIA has no need to send boatloads of javascript to the client, no need to JIT-compile the javascript, and no need to query client-server APIs before anything is displayed, it can deliver the landing page lightning fast.
  5. 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:

Vaadin

Vaadin is nice, but...

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:

  1. 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.
  2. 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.
  3. Semi-static pages: Send fully constructed DOM on initial load. Setup javascript & websocket in the background. Only subsequent interactions are performed RIA-style. Provide hard URLs for links alongside event handlers for SEO & basic accessibility.
  4. 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.
  5. No boilerplate: Auto-wire data bindings and event handlers. Auto-wire dependency tracking for computed values. Auto-wire persistency for view state.
  6. 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.
  7. 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.