Three and a half Roses

The rise and growth of the UI Layer

In the early days of the browser-based internet, the UI layer was gold-paper thin.

Browsers were not even capable of processing user input from day one. Computers were slow and didn’t have a lot of memory or video capabilities. Cascading Style Sheets (CSS), the iPhone, Android hadn’t been invented yet.

And so the logical consequence was that (almost) all the rendering logic was processed server-side. And so the weight of each layer looked like this: a lot of logic and code in the back-end or system layer, then a process layer that also implemented the rendering logic that couldn’t yet be done in a browser:

in_the_early_days

Performance of the devices and browser improved over the decades, the increasing user experience demands of people and the evolution of the client-side software pushed us to improve user interfaces.

The back-end layer partially crumbled into small services, while other parts were replaced by SaaS APIs.

And so when we look at the weight of the layers when building a system today, it looks more like this:

ui_layer_today

Consequences

This however is not without consequences.  Some of the things that were handled by the process layer now must happen in the UI layer, like: orchestration, caching and even CQRS and event-sourcing. 

breaking up the monolith-2

 

The latter is a very interesting evolution as it is a tell for a more global trend : the introduction of engineering practices to the UI layer. 

Componentization (thanks to frameworks like ReactJS), patterns & design systems, libraries…

These are thrilling times 🙂



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About Me

I’m an enterprise architect and have been passionate about Mobile and Architecture for years.

Many years I’ve been designing Mobile apps and back-ends.  Now I’m looking into the next shift: Big Data and Cloud and AI.  Combined with Mobile this is bound to give interesting architectural challenges.