This article is a bit dated given that it was written in 2014.

The traditional 3-tier architecture is dead, or at least its dying quickly. In a traditional 3-tier web architecture the tiers were defined as:

1. Client: HTML, CSS and JavaScript
2. Server: A server-side framework in Java, Python, Ruby, PHP, Node.js/JavaScript, etc.
3. Database: A relational database including stored procedures inside the database

Each tier had a specific job to do:
– Client: render the UI
– Server: business logic (controller) plus generate updates to the UI (view) based on queries run against the database (model)
– Database: data access and storage

So what’s changing? Literally, everything. Every layer of the stack is undergoing a massive change that necessitates a change to the architecture.

Client to UI/UX

TL;DR: The client-layer has evolved from static HTML to advanced, thick clients composed of JavaScript. These new JavaScript apps require a UI/UX API to provide a portion of their functionality. Further, mobile platforms often share the same UI/UX API.

The web client has evolved from HTML, CSS, and JavaScript to JavaScript, CSS, and HTML (where order indicates the importance of the code in delivering a high-quality user experience).

JavaScript heavy clients have become the norm and are table stakes for today’s modern web apps. The emergence of JavaScript in thick web clients (aka Single Page Applications, or SPAs) has given rise to a larger number of advanced UI JavaScript developers who must deliver increasingly advanced functionality in their apps. As a result, modern apps demand more from UI/UX developers and this has driven the need for UI/UX engineers to have control of their own server-side API.

Node.js has emerged as the go-to solution for UI/UX server-side API development, although other scripting languages such as Python and Ruby remain popular choices. Essentially, a Node.js API (or equivalent) is a thin API layer that represents the Model portion of the older, monolithic server-side frameworks.

Further, mobile development for iOS and Android require a UI/UX API. Consolidating this new API requirement within the UI/UX team allows all customer facing application development to move at a faster pace.

The last big driver that necessitates the creation of a UI/UX API is the fact that the UI/UX API calls a multitude of other internal APIs (for various platform services or data services) and/or external APIs. The UI/UX API tier helps to consolidate these various API calls into a single API endpoint that can be called from JavaScript, Objective C/Swift, or Java

Server to Services

TL;DR: The older server-side MVC monoliths have been broken apart into specialized functions. The Model layer has been pushed down into Data Services, The View layer has been pushed up into the UI/UX team, and the Controller is now an entire Services API layer that provides common functionality that is used by multiple apps.

The traditional server-tier has been broken apart into specialized functions. Traditional server-side frameworks consisted of an MVC architecture (Model, View, Controller). These older applications were monolithic code bases that did everything from querying the data layer, running business logic to rendering UI components.

As discussed above, the View portion of server-side MVC has been taken over by the new UI/UX API server.

The traditional MVC server-side frameworks have given way to a more specialized business logic layer, which consists of APIs capable of handling various service-oriented functions. The new Services APIs consist of common Platform Services plus reusable app Services APIs.

The Model layer, or server-side data access layer, has been pushed into a new layer known as data services. Data Services is the newly evolved data team. We’ll discuss the data layer more below.

While it may appear that the server tier has been reduced in scope, the reality is that the Services API layer is the core infrastructure team. Neither the UI/UX layer nor the Data Services layer would be able to develop functionality as quickly as they do without the platform and shared services delivered via the Services API tier.

Database to Data Services

TL;DR: Data storage and query is undergoing a revolution.

Much as the client layer has undergone an explosion of capability, the data layer now consists of a myriad of technologies.

Live was easy for the data team when relational databases were the only option. RDBMS’ provide a fully integrated data environment, complete with the SQL query language, an integrated query engine, stored procedures, logical abstractions and physical storage.

However, the modern data layer consists of a multitude of specialized data components that often separate the query language, the query engine, logical abstractions and physical storage.

Let’s use Cassandra as a quick example. In Cassandra, data engineers write queries using CQL. However, to actually run CQL the data engineer must embed the CQL in Java, Python or another supported language. So, now the data engineer requires an execution environment for their query code and they must give access to the query layer to the Services team and the UI/UX team. The obvious solution is for the Data Services team is to run their own Data Services API layer, which is exactly what has happened. Contrast this with an RDBMS where all a stored procedure is embedded inside the database and the API is the stored proc’s function signature.

Summary

The traditional 3-tier architecture of client, server and database are being replaced by new tiers that more closely align with modern applications:
– UI/UX
– Services
– Data Services.

The UI/UX layer now contains a full stack of its own including rich, thick clients written in JavaScript plus it’s own server-side API.

The Services layer is now more specialized as the view layer has been pushed to UI/UX and the model layer has been pushed to Data Services. This enables the Services layer to focus on what it does best, which is write advanced business logic and provide platform services that are common across multiple apps.

Data Services, which was previously confined to relational databases, now runs multiple data storage technologies, just one of which is a relational database. Data Services now runs its own API layer as well.

These changes align well with modern application development and help accelerate development cycles. UI/UX can deliver client functionality faster by leveraging the core infrastructure provided by the Services team and owns it’s own server-side API to quickly integrate the data provided by the Data Services team.