What to do with the "frontend" in a microservices based environment?

Question

We have recently begun to split our monolithic web app up into microservices, slowly slicing functionality off and rewriting into individual microservices. All is going well except we are unsure of the best way to organise the frontend work. We have split up into product teams with each managing the code for a small number of microservices to deliver a functional area e.g. Search, CMS, Checkout etc with each team having a product owner, tech lead and scrum master.

The issue is that while each of those product teams have their own backend code base we have a single frontend React.js code base with frontend devs sat in each product team. This is causing a number of issues:

• Lack of communication cross product teams between frontend devs
• Problems getting changes made to frontend code the other team "own" to support new features of other teams
• No single technical expert to represent the frontend team, while other product teams have technical leads there is nobody fulfilling this role for the frontend

We were wondering how other people are handling this, and have discussed a few approaches such as splitting the frontend codebase, creating a frontend product team who the business users will typically engage with for new features and requests for data/services would come in to the other product teams from the frontend team but both seem to come with their own set of problems!

Answer 1

The frontend is in a sense the most important part (it's the part the users actually use), it has its own data structures, infrastructure, specialized developers, and it needs to communicate with all the other teams. If the rest of the backend is split up into services, it's the most central part too.

So the only way to work is to let the frontend have its own team, I'd say before you split the backend into multiple teams but that has already happened.

Lack of communication -- the only way for any backend team to have anything happen on the frontend is to communicate with the frontend team.

Problems getting changes made to frontend code -- the frontend's product owner decides what features need to go into the frontend first, nobody else.

There is a technical lead for the frontend.

This is also obvious because one of the benefits of having a clear split between frontend and backend (without which you can't start splitting the backend into further bits, so I'm assuming that you already have that sorted out), is that you could have several completely different frontends that do different things with the backend services. Clearly those would be different products.