Hello.
Welcome to 'Back To Basics'.
I'm Ashwini Rudra, and today we are going to discuss about Headless Architecture.
If you are hearing this terminology for the first time,
let's discuss the difference between decoupling and headless.
Many of the application architecture patterns work well
for a single channel, example a website.
But when the digital experience and user channel grows,
this architecture pattern becomes complex.
Headless architecture is not a new term,
it's a subset of decoupled architecture.
And as you know, in decoupled architecture, you separate frontend from the backend.
User accesses the frontend, then different tiers of backend are decoupled using queue
so that it can scale independently.
You might have seen this pattern multiple times.
Now you think about a scenario when your application can be accessed by multiple channels.
Example, websites, phones, tablets, IOT devices,
smartwatches, AI enabled voice assistance, and virtual reality headsets.
Digital content is getting more sophisticated
and your application user's expectations are rising.
To stand out, you have to build beautiful, responsive and interactive content,
and you have to do it quickly.
So how to do it.
One pattern is independent architecture for each such channels.
Here is a typical serverless weather application.
User wants to know the weather using different channels
and each channel has its own decoupled architecture.
Each channel has API, frontend, business, and database tiers.
But as you can see this introduces resource duplication and complexity.
You can optimize the resources and simplify the architecture.
But how can you optimize this?
The solution is headless architecture.
Let's work backward from the architecture point of view.
Let's solve database tier first.
For our example, which is a weather application,
you don't need different databases for each channel.
For the same content you can use the same DB, or you can use databases
such as NoSQL or Amazon Elasticsearch
based on the dataset requirement.
But you don't have to duplicate data into different data tools until required.
Next is business tier.
This also you can simplify and reuse,
and with application a user need to see the data
either in Fahrenheit or degrees centigrade.
Business logic is going to be the same irrespective of channels.
The main goal to simplify this tier
should be making the business tier device independent.
Next, let's introduce an API for scalability.
We need an API layer so that different channel can consume these APIs.
This will also reduce the complexity.
Now we have architected the application backend
that is now device and channel independent.
Different channels need different kind of rendering logic.
Some needs voice based output,
and some needs different responsive web rendering.
Here using a Lambda function or Amazon EC2,
we can achieve this goal.
This tier can be device aware.
We can again, expose rendering logic using APIs
so that devices can consume these.
Now you can see the backend is completely channel independent.
It's headless.
In simple language, headless architecture means
wrapping up all the business functionalities and logic in a set of APIs.
These APIs can be consumed by different applications and devices.
Now you must be thinking, what is the benefit of headless architecture?
Headless architecture is an ideal candidate for content management system
publishing applications and e-commerce.
The first benefit is using headless architecture,
your developer can develop the frontend using different languages.
This brings flexibility to them.
The second one is, at anytime you can introduce new channels to the users.
I have used this pattern multiple times, and you can use it too.
Click the links below for more details.
See you next time.