Micro Frontends: A Tool to Rule Them All
If you’re a developer working for a multinational company such as JustEat Takeaway.com, one of the challenges you have (other than timezone-related bugs) is keeping up with the various ad-hoc rules, laws, and legislation that every country has. You have to follow specific logic for each feature, process and country you serve.
Since the logistics branch of JustEat Takeaway.com works mostly with employed couriers throughout the European countries JET is active in (and to be honest, this was one of the main reasons I originally applied in 2018), one of the cornerstones my team focuses on is compliance which has a fixed place in our team’s quarterly goals.
This means that every city needs to be operated differently, from varying opening times and the type of vehicle used to deliver so we need to find alternative ways to organise shifts for the couriers.
The work we do helps our planners create shifts for the couriers, which are inevitably complex if they must comply with all 10+ countries JET operates in. This can include the shift length, pauses, resting times and underage requirements, which can often be regulated at a country level.
It’s Not Just Shifts…
Of course, we are not the only team in our department facing the same challenge.
Let’s take routing. It is essential to understand which courier is currently in service and is the most fit to deliver a concrete order. People’s food is not a joke. First of all what does it mean “most fit”? Most fit for whom, for example? For the customer, to get the food as soon as possible? For the courier, to avoid delivering food to a distant location? Or for the business, to optimize the number of orders a courier can deliver per hour?
Not only it’s hard to find the sweet spot, but it is also hard to get to it when operating in very different contexts, with different rules and situations. You got it: different countries need different settings for the very complex routing algorithm.
It’s Not Just Laws and Legislations …
… there are also processes. People have different ways of working depending on their place and culture.
What if I tell you that the geography of Barcelona is very different from the one of Valencia? One is a city with a pronounced altitude difference due to the several hills present in the city (i.e. hard to bike there), and the other is an essentially flat one.
And would you be surprised to know that in some countries, weekend shifts are far less popular compared to others?
Or that the planners of some cities prefer to rely less on the automation tools we provide them, preferring to manage tasks more manually? Or that in some regions the Order Forecast (a tool we use to predict how many couriers we need on the streets) is inherently less precise due to the weather? Not even considering that each city has different opening hours…
The Situation In 2021
In 2021, we asked ourselves this question: how do you manage configurations for a dozen domains and stakeholder groups without having to dedicate most of your resources to it?
For a good few years, me and my team have been responsible for a fairly new tool named City Configurator used to manage the different cities in which the European logistics branch of JustEat Takeaway.com works.
Simple tasks like creating a new city, defining the timezone, the coordinates, and adding contacts can be handled through it. Given that we apply Domain Driven Design, we decided it to be part of an autonomous domain with its own Bounded Context — i.e. not part of any other existing domain of our department — with all the relevant information published in an event-driven fashion and thus available to all teams.
However, my team had already pioneered the possibility to give some stakeholders (i.e. users of our tool) autonomy in changing many settings of the application, for each country or city. We did that by adding a separate section in our beloved City Configurator.
More recently a few other teams and their stakeholders started to be in need of such a possibility, that is a graphic interface where (some) stakeholders could autonomously change the settings of their systems for each country or city.
At this point I seized the opportunity to promote a vision dreamed by a couple of my colleagues and me back in 2018/2019 of a unique tool where the stakeholders could customise the settings of all our logistics tools, for each country or city.
We decided to implement this vision and we identified 3 ways of doing so:
The first one was that my team would have done the dirty job for all other teams. This would have meant dedicating a huge amount of our capacity in serving other teams, de facto crippling our productivity for our own roadmap. Easy to rule out.
The second possibility was to create a dedicated team to take over the development of the City Configurator and make it the so-long visioned tool. This was indeed a possibility, but I voted against it for the following reasons:
- In a fast growing and constantly evolving environment like ours, a team would have had to learn the language and the details of more than potentially 10 other different domains. From Shiftplanning to Routing, from Forecasting to Live Operations, the amount of domain knowledge required would have been huge. This approach is worlds apart from scalable;
- The roadmap of the team would have been in practice dictated by several other Product Owners (POs), who would have fought to prioritise the development of the settings needed by their stakeholders;
- Let’s be sincere. It’s not the most fun tool to build as a developer. Keeping developers motivated for years to build such a tool would have been a challenge, especially for a company like ours that aims to keep and let developers grow for years.
The last possibility was to give full autonomy to each team to build their pages and “embed” them somehow in the City Configurator. And here it came to my mind the possibility to apply the relatively new technology of Micro Frontends to serve the purpose.
As we are always looking for new ways to experiment, challenge our developers and act as a innovator team in our department, and since our Frontend Tech Lead was already investigating the technology, I quickly partnered with the Product Owner and my Frontend developers to propose such an implementation.
The requirements of such an implementation, as well as the offerings to the other teams, was:
- Our team would be responsible for the maintenance of the skeleton app that keeps all pieces together;
- Part of the skeleton would remain the management of the cities served by our logistics department. This would continue to be considered a domain on its own, and owned by my team;
- Every team would have the possibility to add a page per each tool they develop;
- Every team would have complete autonomy in the development of their own page(s);
- Once added to the skeleton app, every team space would have the possibility to independently develop and deploy their tool page(s), without any dependency from my team (i.e. for the techies, no npm modules, no build time integration, rather at runtime);
- Our team would provide an (optional-to-use) React Frontend boilerplate application, several libraries to easily handle common tasks like authentication, and extensive documentation.
The final architecture would look like in this picture, where A, B, and C owns respectively a page of the City Configurator:
Needless to say, the Product Owners and developers of the interested teams were enthusiastic about the proposal, and towards the end of 2021, we decided to add the transition of the City Configurator to a Micro Frontends infrastructure as part of our 2022H1 goals.
Our Frontend developers especially were excited to embrace a new technical challenge. While our Tech Lead was in charge of the initial investigation and setup of the infrastructure, it was decided to rotate for each Sprint the other developers that would have worked in the project, and thus share the knowledge across the whole team. Also, several knowledge-sharing sessions were held in the department’s Frontend tech meetings.
Along the way we also decided to involve more of our UI and UX designers, in order to get a fresh new design for the skeleton application, and get shared components that would be made available to other teams.
Meanwhile, together with the new country migrations we had been dealing with, the needs of country and city customisations increased and more teams showed interest in having their own page in the new City Configurator.
This lead our Product Owner to host a more official presentation in 2022Q2 to the whole department, where the plans and roadmap of the new City Configurator were presented. The overall reception was amazing: almost half of our logistics teams expressed interest in adding their page(s).
With the final release of the City Configurator 2.0 now due in 2022Q3, our vision is finally becoming a reality.
Essentially one of our goals is to make life easier for our stakeholders, giving them the possibility to easily adapt our tools to their specific environment, conditions, even culture. We are sure to be now a step forward in this direction.
Having one central application for all teams, with separate pages independently owned and managed, using shared components to save development resources makes this project a great example of a scalable application setup.
Just Eat Takeaway.com is hiring! Want to come work with us? Apply today
