Anatomy of a SPA (Single Page Application)
Understanding how a SPA works behind the scene leads you to make the right decision when the time arrives…
Hello there! In this article, we will talk about SPA(Single page application) and see how the websites worked before JavaScript and browsers evolved to support the new era of web development. The main goal of this article is to understand the anatomy of a SPA. I’ll maintain this article at a high level to us to understand what’s happening beyond a framework or library that is possible to use to build a SPA. Although this article is not about how to implement a SPA with React or Angular, they will be cited here as examples.
Why Should you understand what’s happening behind a framework?
Learning a framework nowadays is not sufficient anymore, as you probably know, technology is changing so fast that it’s seems everything you learned is not sufficient and you cannot beat that race. That’s an issue today because when you learn a framework like Angular, you learn how to use the framework and not how it works behind the scene.
I wanna you to take a moment with me to think about the browser, if you’re not a beginner at web programming you know the browser has changed almost nothing in the past few years. The main reasons frameworks and libraries change so fast are to deliver more flexibility, productivity, the most security, and so on… but remember, these libraries and frameworks are made by JavaScript and features of the browser. So, understanding how a SPA works behind the scene leads you to make the right decision when the time arrives to pick the next framework or library to start a new project.
Traditional web applications
Before we dive into SPA, we have to understand how web applications worked before. Let’s take a look at how a view is built in traditional web applications/pages.
As you can see, in the first request you received an HTML page, that seems ok, but if you take a look again and if you’re a beginner web developer, that can seem weird because each request you make to get new “data” you receive an HTML page as a response. As you expected, for each request you have to refresh the entire page, which can cause a problem like a flash white, and for that reason, your website can be slow and drive users away, because you have to wait until the redrawing is complete.
At some point when the asynchronously start to spread in the web page design, it was possible to use AJAX, and JavaScript to dynamically update the DOM(Document Object Model), but the process got even more difficult and complex.
Let’s make a list of the pros and cons of traditional web applications/pages:
Pros:
- It’s good for the search engine;
- Simple applications;
- Read-only.
Cons:
- Full page reloads;
- For each interaction that needs new data it’s necessary a request to the server to get the HTML;
- The contents are not reused;
- It’s not easy to maintain.
What is a SPA?
In a nutshell, SPA(Single Page Application) is a web application that doesn’t refresh your page during use. Spa delivers to the user a high experience to the user, that experience can be compared with desktop applications. One of the main advantages to choose a SPA to developed your project is because It doesn’t require plugins on the client-side, you can build your project using only HTML, JS, and CSS. Let’s take a look at the design behind a SPA.
In the diagram above, as you can see, the server is no longer required unless you need to get some data, but in the processes to build the view just the client-side is enough. The main reason that design of the SPA was possible to work was because of the XMLHttpRequest, which allows requesting a piece of data. In that scenario, we should consider that to the client-side doesn’t matter what kind of technology you’re using on your server-side since your API deliver what the client is expecting.
It’s important to remind you that when you choose a SPA over a traditional web application, your stack, practices, and structures are gonna be completely different since in the SPA the only response to the server is to provide the data services.
What’s going on on the client-side?
Now that you have a brief knowledge of what a SPA is and the difference between SPA and traditional web applications. It’s time to understand how the client-side handles the views and business logic. As you already know, there is no mystery in how the traditional web works when it’s necessary to change something on the client-side, but in the SPA things start to get a little bit more interesting. Let’s take a closer look to see how that works.
The HTML file is the initial HTML loaded when you make your first request to the server. If you take a look at the file, there’s only one empty <div/> with an ID. That’s the minimum your application needs to initiate your web application and prevent a full refresh in your page when something new needs to appear or be substituted.
If you remember one of the advantages of traditional web applications over SPA is the search engine, I do think it's very clear to you why a SPA is not good for search engines, your initial HTML doesn’t say anything about your website. If you're building a website that requires to be good for search engines, you should consider that’s a problem for SPAs.
Where are the pages?
About the pages, we will see just part of the mechanism that is needed to handle the routes. During use of a website you probably use the bar’s URL to type an address or change the location of the website, in a traditional website when sending a new URL or using the buttons to navigate in the history, you receive an HTML page as a response. In the SPA these functionalities are still possible to navigate.
As demonstrated above, the Router stays in the middle as an intermediate for matching the route path. You may ask “what happens if the user tries to get into a page that he is not allowed?”, in that scenario is possible to verify the actual state in memory to certify if the user is allowed, if he is not, you can move him. Maybe the user tries a path that is invalid, in that scenario you can configure to move him to a specific route.
With the HTML5 History API, it is possible to use the browser’s history to fall back to another page without refreshing the entire page, what makes it possible, it’s the two methods pushState and replaceState, be aware, older browsers don’t offer support.
Conclusion
As it might be seen, a SPA is quite complex to learn and to comprehend what it’s doing scenes. It’s important to remind you that SPA is organized using modules to not cause a collapse in your variables and your communication with the server asynchronously without blocking the user interaction. The main reason to use a SPA is to deliver an application with the experience of a desktop application and to increase your productivity.
