REX Luxembourg Voxxed days

We had the chance to participate as a speaker at the Voxxed Day Luxembourg 2023 which takes place from June 21st to June 22nd. It is a tech event to discover new concepts, and new technologies or exchange opinions and ideas on our work. I have two conferences during this event that impressed me I want to share with you:

A frontend application to rule them all

The first presentation I attended was a 1-hour conference by Sylvain Dedieu, a software development engineer from Criteo. The goal of this session was feedback on his personal experience regarding structuring a complex front-end application and working with micro-frontends.

His need was to have 2 applications (app A & app B) and navigate through the apps seamlessly for the user, giving the illusion of being on one single website but he had several conditions:

• be able to not be restricted to a specific version or language of a technology
• to keep things simple without any super complex architecture impossible to maintain
• of course, be viable in terms of performances
• flexible enough to make the project evolve without having impacts across the application.

To do that, Sylvain explained mainly 3 approaches :

An approach by libraries

The first proposition was to use NPM to create common dependencies between the two apps. For example, having a “layout” external component used as a library by the 2 apps brings a common colors schema and header component across the pages. Then, the 2 applications would have a different domain: appA.example.com and appB.example.com for example and we can navigate between them by redirecting to the right subdomains delivering an almost-perfect illusion of having one single application. Using “reverse proxy” can also improve the illusion of having one single domain.

One nice thing about using NPM is that you will have its full power of versioning, so you can surely improve your libraries without risking breaking anything already on production till you didn’t increase the version of this particular app.

The cons of using this approach are that we need to avoid making your dependencies take care of too much on your apps, or it’s going to be very hard to maintain. Also, it is possible to have some applications that are never updated so when we want to migrate, it is going to be super hard. Finally, the illusion is great but it is not a real SPA since we have some HTTP redirection between the multiple subdomains, so we don’t fully use the power of frontend frameworks such as Vue or React.

The micro-front-end approach

The second approach is quite similar but here, instead of using NPM as our bundler, we will create real “sub-apps” for each part of our main application. Every sub-app points to its own port and is injected into the main application using a tooling bundle such as Module Federation that came with Webpack 5. Then, depending on the URL of the main app, it is able to know which sub-app it needs to load.

Contrary to the NPM approach, here it is a real SPA in the end, it is not an illusion. Also, the main app will always get the latest version of the sub-apps, allowing it to upgrade the entire application at the same time.

However, it is a little bit more complex from the first approach because we are working with multiple app that needs to be running at the same time, and handling correctly the port injection.

The mono-repo approach

Finally, Sylvain explained that it is possible to build one single project that will have all the sub-apps inside, and everything is handled by one single package.json file. It will help to handle cross libraries and also to run all the apps together without having trouble going on the sub-app X, pulling the changes, re-running it, etc… Here one commit is across all the apps so you are sure to be always up-to-date in local. It works well with the 2 previous approach

At the end of the conference, Sylvain talked about Nx, which is a tool that allows us to have visual feedback on our micro-frontend architecture. It creates a graph where you can see all your micro-frontends together and how they communicate with each other. Also, he showed us that it is possible to allow/disallow some sub-apps to be used by others. For example, a sub-app “UI library” for your project could be pulled by all other services but a “Page A” sub-app should never be pulled by “UI library”, it has no sense. So by doing that, Nx can bring you warnings and tell you that you are doing something that seems to be a bad pattern.

Feedback on bit.dev

Then, I attended to the 15-minute quickie of Lucille Moise, a front-end developer from Serli who wanted to share feedback regarding bit.dev.

She had a situation where she used multiple UI libraries (like Ant design and Material UI) in their application which created several incoherences, sometimes on the same page! So she needed to find a solution to have a seamless experience across the entire application without forgetting the advantages of using a UI library: to create and design an app in a short amount of time.

The answer to that was to create a component library and so, she started to write a tier list of things she would need. Mostly, she wants it to be fast, very collaborative with easy-to-use components, and also easy to work inside the library. To do that she wants to be well-documented and easy to maintain. Two solutions came to her mind: Storybook or bit.dev. She then decided to iterate with bit.dev to see if it would match well the need (because she already knew and used Storybook in the past).

Bit.dev is an open-source toolchain for the development of composable software. It allows devs to create components as you usually would and then import them in bit.dev to have visual documentation available for everyone. Within, we can create pages to explain when to use a specific component, where to use it, etc. Bit.dev also gives us the possibility to visualize the dependencies among your components and create trees of dependencies to find maybe very heavy libraries used only for 1% of its possibilities and also only in one single component in our UI library.

Finally, bit.dev gives us the possibility to publish our documentation in order to give access to the “non-dev” users like designers, and product managers for example.

She used it now inside their team and could see the benefits of having bit.dev:

• The app was released in time and ran perfectly in production
• Newcomers didn’t struggle to work with it
• She saw that bit.dev is constantly evolving
  

For her, it was important to anticipate the need and analyze your components in order to be able to structure it. You can help with bit.dev online examples, and even to bit.dev directly, they are super reactive and with good help.

Conclusion

Overall, it was a very good conference, the chance to discuss personally with all involved people during the 2 days was super interesting.