Ever since I started working on my first real AJAX web components more than five years ago I’ve been a big supporter of the “Browser as a RPC client” architectural concept, promoting decoupling the “web client” from the “web tier” as much as the technology used in each project allowed, and I’ve met both resistance and support from each one of the teams I’ve worked in. Somehow, the thought of treating the “web client” as a distinct and separate entity from the “web tier” managed to evoke either alien feelings or hard-to-forget memories of client-server architectures in the hearts of my fellow developers.
In time, this changed as more and more developers started embracing AJAX and preferring MVC architectures… but we are not there yet. Resistance is still there, justified by arguments like “decoupling will incur extra costs” or “what’s wrong with generating pages server-side, it just works”.
I had my first try at building an application based on the model that I’m describing back in 2008, for my bachelor’s degree thesis and managed to do a pretty decent job considering the time, the maturity of the technologies and the stack that I selected but what I achieved was a lot less than what I hoped for. After I finished with my thesis I implemented a part of the concepts that I used in the projects that I worked on professionally and got pretty good results.
Having this first working spike outlined (at least for me) some of the most important benefits that we may get by using this kind of model, and I’ll try to summarize them:
- it enforces the creation and evolution of a clear and strict client-server API and cleaner code both client-side and server-side – just think about all the code that places objects on the HTTP session just so it can be used later on in a JSPX or PHP template;
- it provides a cleaner role segregation than using templates and templating technologies (think Java Servlets and PHP) – this model allows us to have dedicated “web client” developers that churn out beautiful and usable web interfaces using dummy data providers while server-side developers focus on clean and optimized web tier code;
- having a clear and strict API and a decoupled web client allows faster and safer technological improvements on both the client-side and the server-side – imagine building a totally fresh “web client” in a new technology or building a mobile version while being fully assured that server-side code didn’t just spill into client-side code;
- the “web client” decoupling and clear and strict API allows cross-server-side-platform usage of the “web client” – a lot of effort goes into building a good user interface for a product and having a product framework that works on multiple technological stacks is a big differentiator in this fast moving market. Imagine the same product running on a Java stack and a .Net stack with no code generation, conversions, migrations or whatever… just built using the API and two distinct server-side frameworks built following the said API… that would rock. Because you know, the interface is the product.
Anyway, as apps get more and more dynamic and things just tend to naturally head in this way, and because existing stacks and frameworks got better and better at simplifying browser-server AJAX and RPC-like communication I think it’s time to go with the flow and try to crystallize my ideas, at least at a conceptual level.
This is not a model that suits any type of system but most of the systems being produced today can be built using it.
The web client
This web client (see, I’m not quoting it anymore) would consume server-side services that:
- define the client configuration – dynamic UI configuration, user preferences, etc.;
- deal with data and perform business processes;
- deal with metadata – data about data – how the data that the client works with is structured;
- deal with meta-metadata – data about data about data – don’t get scared now, it’s just a pompous term that means telling the client how the metadata is constructed. If data is defined by a data model, what does the data model consist of… this kind of thing. We’ll cover it later on.
Besides the services, the actual web client code is also served by the web tier, in a static, unaltered state.
Now, why would we need all this stuff? The simple answer is: we need all this complex stuff to make it easier to develop using this model and to eliminate code duplication as much as we can.
Having all this stuff clear and concise in a strict API greatly improves our chances of building to scale too, allowing us to cache the things that are less likely to change (because we surely know what those things are) along with the static web client.
There’s also another catch. Following this model, we can build specialized components that handle communication and dynamic interface construction and apply different themes and user interface concepts faster.
The web and business tier
Having the client decoupled and using a strict and clear API we can have full liberty in implementing the web tier.
Knowing the protocols and API allows us to build reusable web tier components that handle API requests in just about any technology stack running on any platform
Liberated from server-side code that infects client-side web markup and the HTTP session, we can switch to stateless models so that we can fully employ scaling techniques like transparent load balancing and clustering with no worries.
Having a clear and concise API, protocol and communication model will let the developers focus more and more on the business side of things and less on glue and stitching things together.
The overall picture
Although I try not to think of this in implementation terms – like building a framework, because I really hate building frameworks – I always deviate toward implementation and component diagrams, well, here is one for you, quickly sketched in Excel (the ultimate diagramming tool, BTW).
That’s it for now, hopefully I’ll have more on it soon.