Richard Bucker

My Next Framework

Posted at — Apr 21, 2013

I have been reading everything there is to read on the different architectures for building scalable web applications. The challenges are numerous. For example; the benefits of client-side one-page application is offset by the fact that they lowest entry point smart phone and similar appliances are not as performant as they once were. But then millions of uniques a day might have a similar effect on the server-side of the architecture.

So what to do?

(a) by building a proper idempotent stateless REST layer that can either be exposed via an API layer or buried inside your domain would seem to be a good starting point. This is going to let you scale the backend separately from the frontend with few wasted cycles in between.

(b) when building the one-page app use tools that limit your exposure whether the rendering takes place inside your servers or is pushed to the client. For example using template tools like mustache which are supported in a number of different languages like C#, Go, Java, Ruby… etc. But the real trick might be to implement on JavaScript and use NodeJS. But keep in mind that transitioning from a one-page client app. to a server-side app is not without it’s challenges. Currently there are no tools that span the gap; you’re on your own there.
My latest endeavor has me capturing system events from applications, forwarding to graphite, rendering results, capturing test case configuration and test results, and many other build and test metrics. I’m never going to be overrun with users but since I need to expose REST calls for the various systems to publish to… it made the most sense. Also since we are all using state of the art computers the only issue might be lag time to download the javascript. (which is not really an issue all things considered). One additional proof of concept is providing data for status board (from Panic.com).

So for now this looks like the simplest way to divide the work. Test the functionality, accuracy and scale. Add features without dependency on having to update the entire source tree.

If the #1 rule is DRY then the #2 rule is KRIS (Keep RIsk Small).