DEV Community

Cover image for Single-SPA Authentication and State Management with React.

Single-SPA Authentication and State Management with React.

Rolando Niubo
Fighting Code Addiction since 1985
Updated on ・3 min read

This article has been Edited

Doing a Global State in a Single-Spa application is sort of an anti pattern, as it should be in a micro frontend application in general, as micro services should be decoupled. You will come across this idea, some times even from the same people involved in the maintenance of this Micro Frontend frameworks like Single-Spa.

This conflicts with the fact that even though they do not recommend doing a global state, they also gravitate around the Pub-Sub pattern to solve the communication between micro frontends. In the specific case of Single Spa, they use the utility module pattern to store components and other logics to be reused, they even have an example in the documentation of one of their utility modules been used for storing application state and been shared with multiple micro frontends, GitHub Link

So seems contradictory from the architectural point of view. You want to create decoupled micro services in the frontend, but at the same time you realize the fact that they are not really decoupled at all, they just can't in the vast majority of scenarios. And this is because the browser is the intersection point of all data traffic and the very place technology meet with users.

So who cares, let's do it. Let's create a freaking global state.


First I should give you and advice.

If you need your UI sections (micro frontends) to talk each other consider just use a solid React framework as Next or Gatsby, with a good decent file structure you should be able to achieve success.

But, if you just want to deploy different sections of the UI in an independent way or you have another reason and somehow you are determined to 100% use micro frontends, then I recommend Single Spa with React as in 2021. Despite all the issues you might run into with Single Spa, is still in 2021 the only solution big enough and documented decent enough to adopt. Also they have a great community in their Slack chat room and the people involved in the maintenance of the project answer quick and seems good lovely fellas. Also would recommend you to purchase premium courses from them that will help you to understand everything better and will help support them: Premium courses here

That been said, let's create our Auth and Global State.

Build a Utility Module and build your Auth in there, export it most likely as a Higher Order Component or what not, then condition the render of your micro frontends only when you get the user or a valid token or whatever your case might be. Also put in that utility module your Global State using Galactic State, export also all those hooks, and call it a day.

I will just example the Galactic State part as it's a new kid in the hood:

In your Utility Module such as styleguide install Galactic State by running npm i galactic-state or yarn add galactic-state, then do a folder that you can call store with an index file inside and this code as example:

import { createGalactic } from "galactic-state";

const [useUser] = createGalactic({});

export { useUser };

Enter fullscreen mode Exit fullscreen mode

Then export those hooks you just created from the main javascript file of your utility module:

export { useUser} from "./globalHooks";
Enter fullscreen mode Exit fullscreen mode

Now you can import that useUser hook everywhere !!

Now just use it in any Micro frontend just like a React useState :

import { useUser } from "org/styleguide"

const [user, setUser] = useUser()
Enter fullscreen mode Exit fullscreen mode

You will be able to read and write that state from anywhere. This is if all your micro frontends are using only React.

If you actually need Polyglot micro frontends, then Pub Sub would be my guess, although I haven't test it, but at that point I guess you are already into troubles

Bye and good luck

Discussion (7)

alxizr profile image
alxizr • Edited

Hi Ronaldo, thanks for the article.

I would like to ask a question about the cross framework state sharing. In the above example you demonstrate state sharing in multiple React applications and thus you have no problem between them. In my opinion this is pointless and actually a waste of time and effort because you could achieve the exact same thing with a decent component structure inside one React application without having the need for single-spa.

My question is in the concept of micro frontends where you mix 2 or more different frameworks, such as React and Angular, how will you solve the state sharing issue in this scenario ?

I've read the official docs and the official faqs and couldn't grasp the solution for this scenario.

Trying to implement the utility module pattern is not enough because in the case you are using Angular and React. One is JavaScript oriented and the other Typescript. One is built on top of RxJS and the other isn't. This is not, by any means, an issue to avoid or neglect.

Also need to remember that in the example above you used galactic state for global state with hooks. This may work perfectly with React but sure as hell won't with Angular. Will be glad if you also could share a utility that can work cross framework

Thank you,
waiting on your response.

niubo profile image
Rolando Niubo Author • Edited

You are 100 % correct.

I'm also wondering how in a Single Spa project that has a React Project and an Angular project would you share components from an Utility Module. I think the developer would be forced to implement both frameworks in the same Utility Module or create several utility modules? Will be honesty a pain in either way.

In my organization we just tried to use Single Spa because we thought the microservices idea in the frontend would be right for us. But we are seeing the ugly faces of it already.

I personally don't think microservices in the frontend are a good idea, at least just yet. In my very personal opinion a UI needs it's sections talking each other in a dynamic way, unless you are doing something very very custom and unique with very specific purpose. If that is the case and Single-Spa and this frameworks are only used in those weird unique cases, this entire micro frontends architecture will eventually fail and be forgotten.

We are seeing cases already of big companies like Trulia, leaving this architecture because in the long run became for them hard to maintain, it became the very thing they were running away from by adopting the micro frontend architecture in the very first place.

But back to your question, if you go down to a Single Spa project with React and Angular mfes, and need some Global State solution, which by the way, is according to them an anti pattern, because you are going against the decoupling of micro services. But if you just need it, you should be able to get what you want maybe with the Pub Sub pattern, I haven't try though, but it should work, as you are just publishing events in the DOM and subscribing to those events...

alxizr profile image

Thanks mate. This is exactly what i had in mind. It is still a mystery with mfe architecture and until someone comes with a battle tested approach we can only experiment trial and error all by ourselves. :)

tovmassian profile image
Khachatur Tovmassian

this is an amazing article with a lot of knowledge and experience sharing. It was really helpful for me to start writing the auth for our MFE architecture and I learned many new things about single-spa that I didn't know before. Thanks a lot and keep writing such kind of great and mature articles.

niubo profile image
Rolando Niubo Author • Edited

Thank You for the feedback!

Very happy has been useful some how!

alexandprivate profile image
Alex Suarez

Dudeeeeee, this is great!!!! This article is gunpowder, for everyone out there, starting with single-spa this is a must-read article, congrats Roli, keep going!!!

niubo profile image
Rolando Niubo Author

YW I hope it helps somebody!