Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Learn about access management practices and technologies.
Learn to manage user accounts and access at scale.
Understand multi-tenancy, a foundation of shared computing.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
The software development world has changed dramatically over the last few years. Following the SaaS revolution, almost no software products are sold today outside a cloud and subscription model. The complete adoption of the cloud model has laid the ground for a major rise in new SaaS architecture concepts.
While Monolith applications were the standard 15 years ago, microservices reign on the backend side today. More and more applications are being developed as micro frontends as well.This post will follow the evolution of SaaS architecture: from monolithic applications through the microservices era, to today’s micro frontends. Our demo application for this use case will be a SaaS product called LoudAPI. The product provides API and services monitoring through it’s analytics dashboard, APIs and services monitoring dashboards, audit trails and configuration.
The evolution of the SaaS architecture started with the Monolithic approach, which is straightforward and the easiest one to build. You take ALL of your APIs, Databases, Services and UI, and push them ALL into one executable process. Our application will be bundled together, where the presentation layer will interact with the controllers to make API calls which interact with the database via a single data layer.This approach (below) is also known as the MVC (Model — View — Controller) approach, as the data access layer takes care of the Model, the Controller takes care of the logic, and the View takes care of the presentation.
The MVC approach will work most of the time when you want to build a really lean MVP through a quick hackathon. It’s more suitable for IO-driven applications than for event-driven applications.
The cons of the monolithic approach are clear (and it’s not as though I’m telling you anything new here ????):
Getting yourself familiar with the code — Monolithic applications normally mean huge code bases. When working as a new developer on a huge code base, the onboarding process gets really complicated.
Learn first hand how easy it is to get your SaaS enterprise ready.
So the next phase (after the quick PoC) in the evolution of the SaaS platform architecture is to build the SaaS application using microservices.
How should we split it?
Splitting our LoudAPI monolithic application to microservices looks like this:
Splitting the SaaS application architecture to microservices gives us a lot of benefits:
So we’ve scaled our application backend and started gathering increasingly more customers (the growth stage). Now we’re faced with the challenge of having our frontend as the application bottleneck.
Every change which requires a UI tweak depends on UI developers’ resources, which makes the development process suboptimal (to say the least).
In addition, how can we build a domain-driven team if all the frontend development is still being handled by the singleton UI team?
How do we deal with the monolithic frontend? Well, how about micro frontends?
The idea of developing micro frontends is to build a web application as a set of independent features and components built by independent teams. When all components and features are hosted on one UI shell, the experience of the end user is seamless.
Using this approach, we can easily reach independent product and feature teams consisting of UI, backend and Devops engineers which can take care of their own product / feature lines without dependencies on other teams. Cool, isn’t it?
Using the micro frontends architecture as part of our SaaS architecture we will result the following architecture:
Each of the domain-driven components is being developed on the same team with the backend developers, meaning closing the loop much quicker and eliminating unwanted dependencies.
The communication between the components and services goes through the API gateway, and the application infrastructure shares the authentication token and gateway URL with the domain-driven components so they can access the relevant services securely.
The micro frontends approach is available through two deployment models (speaking from the frontend side):
According to this approach, each domain-driven team is responsible to publish an NPM library and to trigger a build and deployment operation for the entire dashboard. Upon publishing the new dashboard build, system users can see the new UI.
The pros of the dynamic module resolving approach:
However, the cons of the dynamic module resolving approach:
When using the dynamic module resolving approach, the main dashboard UI is built using placeholders for each of the domains without actually including them in the build.
I know it sounds weird, but bear with me…
This approach’s flow starts the same, but then takes a detour from building the new version of the dashboard. This is what it looks like:
The idea of downloading dynamic bundles and extracting them to their placeholders is applicable using the awesome webpack capabilities available on modern UI frameworks today.
The pros of that approach:
However, the cons of that approach:
Over the last couple of years we’re witnessing a rise in the popularity of the Jamstack concept.
In most cases, referring to Jamstack is done for low-code / no-code web applications, but we can find a lot of conceptual similarities between the micro frontends approach and the Jamstack widgets approach.
The independent widgets approach (popular examples are auth0 login form,algolia search bar, etc.) already runs using the Jamstack approach for SaaS widgets.
Jamstack apps essentially enable operational excellence, reliability and security. This is because they minimize the moving pieces required to deliver the application, while giving it limitless scaling capabilities. There is also less exposure of attack surfaces for bad actors.
So: Could it be that the world of SaaS architecture and development is approaching an era where the company domain-driven teams will build the core functionality of the SaaS applications, while the rest of the business agnostic components will be micro frontends on your SaaS application?
Looking at SaaS architecture and development trends, and given the fact that the technologies and concepts are already there, I think that the answer is clear.
Sounds interesting? Watch out for the next installment: Using Jamstack to develop a secured SaaS widget end to end.
Start For Free
Rate this post
5 / 5. 1
No reviews yet