Over the last 3 years we have been steadily splitting up the monlith code base that powers the AutoTrader website.

The Monolith

When we started this process we had a large (several million line) monolith codebase that was being released daily. A new architecture was based on micro-service and micro-frontend architecture. This would allow squads to work more independently and faster on smaller more specific codebases.

Micro-services and GQL

As we split the data layer we created several micro-service around domains. This worked welll and the services were a mixture of NodeJS and Java depending on the domain area, NFRs and team skills.

To enable this data to be easily utilised in the mirco-frontends we created a graphQL server that could stich together these various domains. We had a single cluster of GQL servers using apollo-server. The architecture for the server was simple using schemas, resolvers, models and connectors.

Now we have connected over 40 services to create a large data graphql. This makes frontend development fast and powerful. The codebase has grown over this time and lots of developers have to edit and maintain this codebase.

Conclusions

Being able to access data from seperate services without over-fetching data is very powerful. It has enabled teams to move quickly. It can be easy to see which clients use which fields in the schema.

Client queries can become very complex and this needs to be monitored and managed. Using complexity measures and tracing can help with this.

The every growing codebase goes against the reasons we started to split the monolith. Moving to a federated structure allows the micro-services to manage their parts of the schema. With services owning parts of the schema and extending other services schemas.

Follow me on twitter @andyianriley
or see andyianriley @ linkedin.