Frontend side architecture evolution (MPA, SPA)
Frontend web development has come a long way since the early days of the Internet. With the increasing complexity of web applications and the demand for faster and more dynamic user experiences, frontend architecture has nothing to do but evolve.
In this article, we will explore the evolution of frontend architecture, focusing specifically on the shift from multi-page applications (MPA) to single-page applications (SPA).
Whether you’re a seasoned developer or just starting out, understanding the evolution of frontend architecture is a key to building successful web applications in today’s fast-paced digital landscape.
If you are interested, let’s begin.
Where it all began?
Back in the good old days, every application was a big ball of mud. What blessing days were those. You could write spaghetti code and be proud of yourself 😌
However, computers became more powerful, the user’s demand increased which caused application’s complexity to grow. It became much harder to maintain big applications, so we had to do something.
The first thing that developers solved was splitting UI from business logic. Depending on UI framework, different MVC-like patterns were born:
That helped for a while, but not so much.
Could you gamble, which of those three components from above has the most tendency for change? While Model is just some business logic written in the age of dinosaurs. Controllers serve to be men in the middle. All the regular users see and care about the most is View. The better View is, the more excited your users become. That is why it so often changes and gets improved.
Nowadays, computers are used not only by scientists but by regular users tool. The console line interface is no longer a thing. People want to press buttons and see images of pets. There is no way for UI but just to evolve.
While there are embedded applications like Word, Notepad, and so on, what I, as a web-developer, care about the most is the evolution of websites. 🌐
A typical web application implies client-server architecture. It sounds fancy, but it isn't. Both client and server are just regular computers 🙂. Your users have a simple computer called a client and there are somewhere in the world another 10 times more powerful computer without a monitor called a server. It just has to be this way. One server serves multiple clients, so it has to be more powerful. That is why it is called thin-client and thick-server.
However, that is not always the case. Let’s see why.
MPA
In the 90s, technologies were so pathetic, that a computer 10 times weaker than your phone would fit an entire room. While a regular user could spend all their leisure time with the most modern and mind-blowing application available — Paint.
In those days, websites have just begun taking root. They all were newspapers alike. Every time the user pressed a button, the entire page would refresh.
This approach is called Multi-Page Application (MPA), since your application, surprise-surprise, consists of multiple pages. With it, on every user interaction, the browser sends a request to the server and receives a brand-new page, causing a light show on your screen. No wonder, epilepsy was such a common disease 🤔
Surely, I am exaggerating here and make it sound like something outdated and out of fashion. In practice, there are still a ton of those sites. They are much simpler to write, to support, and they take less memory on the user’s device.
Here is an example of how it can be implemented using ASP.NET MVC:
[Controller]
public class ArticleController : Controller
{
[HttpGet]
public IActionResult GetArticle(int id)
{
// manipulate the model
var article = new ArticleModel().Get(id);
// render a view
return Content($@"
<html>
<img src='{article.ImageSrc}' />
<h1>{article.Title}</h1>
<p>{article.Preview}</p>
<button>Load More</button>
</html>
");
}
}As you see, MPA is written in a server-side language and runs on a server, where the source code of the application is not available to the public. The browser just receives and displays pure HTML.
SPA
Surely, it could not last for a while. Technologies does not stand still. They are progressing. Hardware become harder, better, faster, stronger. It all resulted in cheaper, more powerful and globally available computers.
Users were getting tired of those wiki-like websites. They wanted a text to change its background, shake on hover, appear dynamically, and so on and so forth.
All that magic is possible, thankfully, to JavaScript. However, JS is not the only motor of progress. It allows the creation of fancy animation, but that’s it.
The real culprit of all upcoming events is AJAX. This revolutionary technology allows sending and receiving data from the server without refreshing the page!
In addition to our regular page request, we have to add a new one, which will only return a part of the page:
[Controller]
public class ArticleController : Controller
{
[HttpGet]
public IActionResult GetArticle(int id) { . . . }
[HttpGet('load-more-from-server')]
public IActionResult LoadMore(int id)
{
// manipulate the model
var article = new ArticleModel().Get(id);
// render a view
return Content($"<p>{article.Text}</p>");
}
}Then with a little help from JS and Ajax we get that data and display it:
<html>
<img src='imageSrc' />
<h1>What is Lorem Ipsum?</h1>
<p>Lorem ipusm</p>
<p id="more"></p>
<button onclick="loadMoreClicked()">load more</button>
<script>
function loadMoreClicked() {
const ajax = new XMLHttpRequest("GET", "load-more-from-server");
document.querySelector("button").remove();
document.getElementById("more").innerHTML = ajax.responseText;
}
</script>
</html>Quickly enough, developers realized that having part of the HTML in one and part in another sucks. So we agreed to send raw data from the server in JSON format, while an additional HTML-markdown can be performed on the client.
It is fine if you build only a few pages with such approach. However, when it is an entire application, stuff got messy really quickly, considering the fact JS is known as… how to say it properly 😬… not a very bug-sustainable language 🙃
That is where React, Angular, Vue and other client-side frameworks enter the stage. Basically, it is a ton of JS code written by somebody else, trying to bring some standards and restrictions, so we don’t have to get our hands dirty and shout our legs.
As you see, you receive a single HTML page on an initial request and all the upcoming ones are just AJAX communication. Hence, the name Single Page Application (SPA).
You have to write two applications, one written in a server-side language and running on a server, while another running in the user’s browser with client-side language (likely JS, until they figure out how to put C# inside your browser 🤔).
This time, your browser doing quite a lot of work, and may even contain business logic, so it is fair to say we have a thick-client and a thin-server.
Summary
In this article, you have seen a reason for a shift from MPA to SPA. Surely SPA is not the end of progress. Damn technologies, continue developing. Things got so messed up, that now not only the client can request data, but the server can send it to the client too. With the usage of WebSockets your UI finally gets what it was asking for — real-time communication.
Frontend became, so complicated that they even start mimicking the backend. Do you remember as at the beginning we were talking about MVVM patterns? It was used to separate business logic from UI on a server. Now it is used by the client to do the same thing.
They have their own Database called Redux. Microservices became micro frontend. And so on. I think you got the idea. However, that is a topic for another article, meanwhile, we are going to close down. 😉
Let me know into the comment section whenever you like this article 💬 Clap if so 👋 Support me with a coffee ☕ And follow to receive more ✅
