Our Journey Into μFrontends

Rate this content
Bookmark
Slides

Building products using Test Driven Development with React and Atomic Design has become my modus operandi over the years. Some products tend to grow in complexity and it is crucial to have a good workflow to keep them healthy and scalable. The time has come to add another player to the game - enter Micro-Frontends. This talk will share a practical example of this setup, some lessons learned and the bumps that were hit to get there.

This talk has been presented at React Summit 2023, check out the latest edition of this React Conference.

Watch video on a separate page

FAQ

The speaker is Rita, a software developer at Volkswagen Digital Solutions in Lisbon.

The text mentions two teams: the Falcons and the Eagles.

The problem was integrating the products developed by the Eagles into the Falcons' existing product, leading to issues with manual processes and version synchronization.

The speaker explored the use of micro-frontends as a solution to the integration issue between the Falcons and the Eagles.

A micro-frontend is an architectural style where independently deliverable frontend applications are composed into a greater whole.

The proof of concept used a mix of bundlers and technologies, but ultimately chose ES build and React for their speed and efficiency.

The micro-frontends were deployed to AWS, with the results stored in S3 buckets.

The team faced challenges with transitioning infrastructure, newness to AWS, and stringent security restrictions and policies from Volkswagen.

Key learnings included the importance of identifying domain objects, the debate over monorepos versus individual repos, and the successful use of React without additional frameworks.

The team achieved seamless deployments, independent team collaboration, and improved end-user experiences.

Rita Castro
Rita Castro
11 min
06 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Welcome to our journey into micro-frontends. We integrated products using a dependency called the card tracker. The manual process between teams raised questions about version control. Microfrontends provided a seamless developer experience and allowed for the cleanup of technical debt. The approach also paved the way for a microservices approach in the backend.

1. Micro-frontends and the Falcons and Eagles

Short description:

Welcome to our journey into micro-frontends. My name is Rita, a geek at heart and a software developer at Volkswagen Digital Solutions in Lisbon. Let me tell you a story about the Falcons and the Eagles, and how we integrated their products using a dependency called the card tracker. It works.

Welcome to our journey into micro-frontends. Let's go.

My name is Rita. I'm a geek at heart. I'm also an avid collector of labels, painter of mandalas, master of Kirby and King Dedede. I'm totally convinced to use my bike to go everywhere in the city. Mother of Pedro. He's four, he likes legos, so do I, it's been going great. I'm also a software developer, and I work for Volkswagen Digital Solutions in Lisbon.

This is the amazing crew that I work with. Previously on React Summit, I have already told you a little bit about how we build our products at the SDC. If you haven't checked it out, please go and check it out. But I would like to add a little bit more to that story. So here it goes. Once upon a time, while the Falcons were building and delivering their products, they did a lot of user research. And through that user research, they identified that the dealers were interested in a new feature, something that would bring a lot of value to them. But this new feature, it was complex enough and big enough that it could be developed by its own team. So the Eagles were born. But it wasn't really good enough to have for the same end users to have two different products being used essentially. So we kind of decided, okay, but we would like to have whatever the Eagles are building integrated into whatever the Falcons are already delivering. So how could we do this? Okay, we decided, very well, the Eagles will create a dependency, the card tracker that will get published into a private registry that we can access, and then the Falcons will go and install it. Okay, seems like a good arrangement. So we set up a workflow between the two teams. First of all, the Eagles, they commit, they push, they essentially, they develop and they bring the product to life. They bump their package.json's version to be controlled in which version we are, though. Then we publish this dependency and we wait for a pipeline to run. And we wait, we wait, we wait, but the work doesn't end here. Where does it go? It goes into the Falcons. On the Falcon's side, you need to bump the card tracker's version on their package.json so that you get a new and fresh install, but you also need to commit and push so that you can trigger the changes on the pipeline and the new feature gets alive. It works.

2. Challenges with Manual Process

Short description:

The manual process between the two teams raised several questions. Who would take care of pumping the version on the Falcon side? How do we track it through the backlog? Should the Eagles pump the version whenever we build something? These questions existed only for an ecosystem with two teams, and the bigger the team, the more questions and problems would arise.

It was functional, but there were several issues. First of all, it was a manual process, so there were a few steps between the two teams that needed to be synced. It inevitably questions, what else would race? We published, have we not, whatever. Most of all and the key thing, who would take care of pumping the version on the Falcon side? And most of all, how do we track it through the backlog? In which backlog, the Eagles or the Falcons? You got to sync it. And should the Eagles pump the version whenever we build something? And whenever we deliver, should we bump? Questions. And these are questions that existed only for an ecosystem with two teams. So the bigger the team, the bigger and the bigger amount of questions and more questions you would have and more problems you would face.