Azure Cheatsheet CI/CD CLI Commands DevOps dotnet github IDEAS JavaScript Linux Node.js Pipelines programming React Security SonarQube TypeScript

Single Page Application (SPA) vs Multi Page Application (MPA)

Single Page Application (SPA) vs Multi Page Application (MPA)

If you want to decide about what technology you want to make your solution, one of the things to consider is if it should be Single Page Applications (SPA) or Multi Page Application (MPA). I see some teams decide to go with SPA because it is shiner, or MVC because they are in the impression that it is easier. But “right tool for the job” at the end of the day makes your life much easier! so lets see when to use SPA and when to use MPA.

SPA vs MPA

SPA Pages are normally a single page that heavily relies on JavaScript to render the pages on the client browser; some popular spa libraries are React, Angular, Vue . MPA Pages are normally rendered and served on the server; examples are WordPress, MVC and …

SPA pages are faster when you only want to change a specific part of the page. You don’t want your user to wait for the whole page to be loaded. In this case SPA give you a better user experience.

On the other hand, let’s say you have a blog or a web-shop and you have specific URL for each of your pages. ex . domain.com/my-awesome-product that points to your awesome product. Then for SEO purposes you want the URL render the page as html tags (opposite to react normal behavior that loads all JavaScript and then the JavaScript render the objects dynamically on your browser). This helps the user to see the content of the page faster, moreover, it is possible to cache the whole page as a static file for that URL. Another advantage of a real html page is when you feed it to Facebook, LinkedIn or similar; they can create a meaningful thumbnail of your page. For such use cases MPA is a better fit. Here is some ideas to consider:

Content of the pages caching

If you have a portal that users log in and interact with it (like a bank portal page), the SPA solution is perfect because it loads once and then user interact with it. In result it updates that part of the page that needs to be updated. If you think about it, it is useless to cache portal pages (as full html page) with changing data of each user, because they are all different and personalized based on users data.

But if you have a blog or web-shop (other than checkout section that is personalized) most of information in each page is the same for everyone (at least of you designed it with correctly) so basically you can cache the most of it as a finished page and serve it much faster and less load on the server, as well as very fast serving resulting a better user experience (more likely user visit another page thus more money)

User Interactions

For SPA pages (back to bank portal example), users come to the portal via specific URL, interact with the UI (transfer some money) and live the portal.

For Blog or Web-shop (other than personalized parts) people are likely come to a random page via search engines or advertisements, read some static information most likely leave or click on a link on your page to visit another page.

Data transition

For the bank portals like solutions, the amount of information sent and receive is very low but it relay on the backend. On the other hand, for blog like solutions there not much backend jobs but querying the database and serve relevant information to product or post.

Conclusion

Although SPA is shiny, MPA has its own use cases. SPA is best for situations when users logs in and interacts with UI. And MPA is best for cases like blog or web-shop where each page is a specific content and has many visitors.


Leave a Reply

Your email address will not be published.