Our microsite architecture

How we accelerated the frequency of releases and the independence of the teams for the site Subito.it by applying a microsite approach

By Alessandro Grosselle, Senior Frontend Engineer

Subito is a re-commerce generalist marketplace and part of Adevinta. At Subito, we are organised into different teams, each with well-defined objectives. For example, there is the Content Team responsible for rendering ads and listing announcements, and the User Team responsible for the account authentication process.

Each team is autonomous and independent, with specific result-oriented goals and responsibilities.

From a technical point of view, following this type of organisation as closely as possible is a very stimulating challenge:

• A team should be able to release a new feature without waiting for other teams.
• In case of bugs or malfunctions, responsibility should be clearly assigned.
• To minimise dependencies, we must build components that are as decoupled as possible; or better yet there should be no dependencies between components from different teams.

Subito’s backend has brilliantly tackled this challenge by implementing a microservice architecture. Like many of you, we started from a monolith website and wanted to implement an architecture that would allow the various teams to work as independently as possible. How did we achieve this?

The idea

We were looking for a microservices-style solution that could be easily integrated and, above all, implemented without interrupting the product’s evolution. We also wanted it to align well with our technological choice of adopting “Next.js” as the web framework.

During this study phase, one of the most important activities was defining the various responsibilities. The output was very interesting because it allowed us to understand that ownership could be at the “page level” rather than at the level of individual components. For example, the saved searches page belonged to the User Engagement Team, the login page to the “User quality” team, and so on.

Here’s the main insight: our monolithic architecture could become an architecture composed of many small independent sites, where each site has, at most, a few pages. Each microsite then belongs to a specific team:

• Each microsite has its own git repository.
• Each microsite has its own exclusive release pipeline.
• Each microsite has its defined routes.
• Each microsite has a defined team (obviously).

We unimaginatively called this a “microsite architecture.”

Development

An architecture like this seemed immediately actionable and implementable without heavily blocking product activities.

We gradually migrated all the pages, step by step. Starting with the login page, we created its repository, Next.js app and defined the route on Akamai.

The work to take the “first” microsite into production was the toughest because as Frontend Developers, we didn’t have much experience in CDN configuration and deploying individual applications in our cluster. But with the support of our Platform Team, we completed the migration successfully.

During our second migration, the favourites page, we realised that the process was always the same:

• Create the repository.
• Create a Next.js app, applying the same layouts, header and footer.
• Define the pipeline.
• Define the route.

From this, we understood that to speed up the migration we could implement a scaffold based on Next.js, with everything needed to develop and deploy a new microsite. Where automation was not possible, we created guides to help developers bring the microsite into production. For example, route definition is not automated yet, but is easily configurable from the Akamai dashboard. For this step, we created a guide which we’ll discuss more in the next section.

What if Team A wants to include a component on Team B’s page?

This is clearly a legitimate requirement. For this case we defined a process:

1. Team A implements the new component in our shared monorepo, wrapping it in an ErrorBoundary component to “catch” the error and prevent the entire React tree from breaking:

<ErrorBoundary fallback={<p>Something went wrong</p>}>

<Profile />

</ErrorBoundary>

2. The component is released with its own version in our artifactory.

3. The component is then included at build time in the project of Team B.

In this way, Team B’s project contains only a few lines of code from Team A: importing the component and using it. And the page always belongs to Team B, hosting a component from Team A.

Conclusions

Today, the Subito website is mostly composed of microsites.

The monolith is still online but only serves a few pages (less than five) with very little traffic. Ironically, we can say that the monolith has also become a microsite itself.

This approach works well for our context: we are agile, able to deploy quickly and have a clear technological division. Of course this is not the only architecture approach; the right one for you will depend on how your company is structured.

From our experience, we have learned that before diving into an architectural restructuring, it is always good to pause and identify the solution that is the most feasible. This may not be “the best” solution, but it will be achievable — and it will work.

To conclude, years after adopting this architecture, we can evaluate the pros and cons of the approach chosen over time:

Pros

• Maintenance of a microsite is much simpler. For example, updating to React 18 for a project with one or two pages is much easier than updating an entire application that may have involved many developers and teams.
• Each team can experiment more quickly. The project belongs to the team, and the app belongs to the team. They are free to integrate new libraries, which will positively or negatively impact their team.
• Due to this page-level separation, the production deployment of pull requests has increased, requiring less time to obtain approvals.

Cons

• In Subito, we have a monorepo where we share common components among all teams, such as the header and footer. Updating these components in all microsites (e.g., adding a new item to the footer) manually is very tedious. Currently, it is still a manual process, but fortunately, the frequency of updating the header and footer is very low. (Spoiler: we are working on automating these types of updates).