We’ve recently reworked the web interface for our analytics product, Rich. We’ve worked on it continuously for the last two years, evolving it along with the product, and even rewriting large chunks of it a few times. This time we’ve taken the step and brought Rich into the land of fat clients — not customers with deep pockets, but pure client side web applications.
It feels like a great fit for us, it’s done wonders for the speed at which we can prototype new features and iterate the presentation until it shines. Here are three signs why you should do the same:
Sign #1 - Dumb or immutable data
The first reason behind our decision is that Rich is not an average CRUD-application. Many of the things supplied by server frameworks like Rails solve problems that we simply do not have. The numbers displayed in the reports has already been crunched and only needs to be visualized, and it’s read-only. In short it means that we can’t really do anything heavy with it. Sure, we can compare different metrics with each other and do some simple math, but it’s all quite trivial.
The only data that has not been calculated in advance is very dumb data. It’s things like accounts and users, some metadata about sites and ads, but all in all it’s a very small data set and doesn’t change very often.
Now, if you rarely have to serialize/deserialize/validate/write data, then letting the client side code work with it directly instead of involving anything but the thinnest server makes sense. Why add superfluous abstractions?
Sign #2 - Complex presentation
Finally we realized that the server side code only solved trivial issues for us and didn’t do anything about the hard problems. So when faced with the choice of making the simple problems trivial or making the hard problems a bit easier, we decided to go for an architecture favoring the latter.
Sign #3 - A need for a sharp line between data and presentation
The frontend developers can focus on the frontend without having to touch the backend at all. They’ve become consumers of the server interface. At the same time, the backend developers don’t have to think about presentation at all. They only have to expose an interface for getting (and occasionally writing) data.
For a sole developer, this separation could have been an obstacle (even if I doubt it), for a team though, it scales very well.
Making the client far heavier than the server has not been easy in all regards. For example, handling good old form-submissions is not as trivial as it was with Rails. I would definitely think twice before reengineering an average, CRUD-heavy, application like we’ve done with Rich. But if you happen to be sitting on a database that is rarely (or never) written to, having a strong presentation focus and working in a team of people with very different skills there’s no need to think twice.