How to setup the project in micro frontend architecture

Karol Wojdyła — Wed, 17 Jul 2024 09:30:10 +0000

The aim of this article is to show you how I designed a frontend application in micro fronteds architecture. At the beginning I would like to highlight all decisions I've made are based on my experience and in other environments might not be suitable, but I don't want to discuss what makes sense or not at every step of this series. My goal is to show the process of raising an application, starting at choosing tools and ending on deployment process. Simultaneously I'm curious about your opinions on what could be done better, which ideas will not work under given circumstances. Each and every comment is very appreciated, so please leave a comment on what you would do in another way.

At the beginning I will say I base on real, commercial experience. The project was in the initial stage of development and there were three separate apps and each application had a dedicated backend service. I was given couple requirements. Consistent UI written in React by using MUI as system design, a user might have access to couple apps. This requirements made micro fronteds have a sense. I've saw pluses from perspective of end user. One URL, ease navigation between apps, the same UI. I saw advantages from developer point of view as well. Managing of code in the same way for all apps, we are not developing the same view for three different apps (eg. sign in, settings page). We are sharing components and themes easily. Of course like everything this approach has disadvantages - you must be aware of it - but I don't want to focus on that.

Topics I would like to touch in this series:

Setting up the app
Routing
Internationalisation
Common components and managing of themes
API integration
Authorisation and token refreshing
Infrastructure and deployment

1. Setting up the app

I've decided to use NX to manage monorepo and apps. In the moment you will see that tool is doing a lot of things for you and you don't have to take care of webpack, eslint, etc (at least at the beginning). We use a couple commands and the backbone of the app will be created. This significantly speeds up and simplifies the process of building micro fronteds. Webpack is using module federation but nothing you have to do manually, because NX is doing the whole job us. Storing the entire codebase in one repo from my point of view turned out to be the best choice. It eliminated the process of releasing packages with shared code, linking of packages during development and a couple other issues.

Let’s start with creating an NX workspace. At that moment we are not creating an app itself but just a directory with NX configuration. In the future NX will know that this space is dedicated to it and can work there without any obstacles.

npx create-nx-workspace@latest

As a result of this command a new directory called myorg will be created. Enter that workspace and we are starting from adding React plugin to NX.

npx nx add @nx/react

Just now we are ready to add React apps to our workspace. The name of them depends on you. I created a host app (called portal-ui) and three remote apps. Please bear in mind the directory directive, which tells NX to put everything into the apps catalog. For me it’s easier to have all apps nested there but you can skip this parameter or name it in another way. I’ve decided to not add a library for styling and e2e tests.

npx nx g @nx/react:host portal-ui --remotes=billing-ui,invoicing-ui,catalog-ui --directory=apps/portal-ui

In the ideal "Micro fronted Architecture" each micro fronted has its counterpart on the backend side. For the purposes of this article let’s assume we have one microservice written in Node.js and will be dedicated to portal-ui. The rest of the apps have backend services hosted outside of our monnorepo.

Our server will be written in Express and therefore we gonna start from adding appropriate plugin to NX:

npx nx add @nx/node

Below command creates a portal-svc, dedicated to portal-ui backend service.

npx nx g @nx/node:app portal-svc --directory=apps/portal-svc

I’m pretty sure you have noticed I’ve added a postfix for every app. For React it’s ui and for Express it’s svc. On the first glimpse it might seem redundant but when in monorepo there will be more apps and fronted counterparts in the backend then you see that adding it to the name at the end makes sense. You can easily distinguish which app is frontend and which is backend. Of course you can add your own postfixes but in general I think adding it to each app is very good practice.

If you are going step by step with this article, the project structure should look like in the below image. All apps are nested in the apps directory. Each and every app has its own project.json file, which contains all settings of the project. Among others, starting of the app, building, etc.

The last step in that section of the article is running the app

npx nx serve portal-ui

By default the portal will be accessible at http://localhost:4200 address. When you enter there you will see NX provides basic UI and working routing. In the coming articles we will touch everything and adopt it to our requirements.

Free alternative to GSuite

Karol Wojdyła — Mon, 24 Jan 2022 07:53:47 +0000

Google closes GSuite and from now all accounts will be transferred to Google Workspace, and therefore will cease to be free. Many people used GSuite only because it was a free service and you could connect your own domain to it. Probably some of you have asked yourself what to do in this situation - buy a paid account or look for another solution.

If for some reason you don't want to pay for Workspace, I am here to help. You can look for other email provider that allows you to connect your own domain. I used to use Yandex mail - but some emails ended up in spam, so I gave up. This time I would like to use GMail so I decided to use an alias. I just need to put a contact on the website and it's nice if it's on the mayann.app domain. I know that if I answer an email, it will be from the GMail domain, but that is not so important to me.

This solution gives me all the advantages of GMail and I use my domain. This is definitely not a perfect solution, the message passes through additional servers, so someone can know the content of the email and we are addicted to this intermediary. However, this does not discourage me, initially I used improvmx.com and everything worked great, but after some time I decided to move to Cloudflare for two reasons - it is a large company, so there is less risk of a failure and I have everything in one place. Both sites are free, so you can try them out and choose a better solution.

Setting up Cloudflare Email Routing is easy. You enter the alias and the address to which the email will be redirected, and basically that's it.

This is an article from the series on how to maintain an indie startup at a minimum cost, in the next episode I will write how I keep a blog for free. Everything I write about is tested on my random data generator indie startup.

DEV Community: Karol Wojdyła

How to setup the project in micro frontend architecture

1. Setting up the app

Free alternative to GSuite

#shortAndToThePoint