Avoid these GraphQL pitfalls

Having made a bet on GraphQL Federation 3 years ago, Netflix knows a thing or two about the potential pitfalls. Stephen Spalding walks us through a few that he calls Microservice Madness and Schema Anarchy.

To avoid Microservice Madness, Stephen suggests approaching your graph in a similar way to the nutritional advice, "Eat food. Not too much. Mostly plants."

"Use Federation." For a few people, a monolith might work well for. But for the rest of us (particularly those with multiple teams contributing to the same API) federation is a much needed solution. "Not too much." Be thoughtful about how you break up microservices. If you have more services than you do teams, could it be worthwhile to step back and ask "why?" "Mostly along team boundaries." The supergraph is a technical solution to a people problem. At Netflix, federation is a way to break out services incrementally as they grow, by teams, without breaking the contract with clients.

Taking on Schema Anarchy, Stephen offers up some great tips including creating a schema working group, documenting your schema best practices, systemizing and democratizing schema update proposals, and finally using linting to give your teams more space and time to make the important human decisions.

You don't have to crank Federation up to 11 straight out of the gate, advises Stephen. Start simple and crank it up as you go. Use Federation. Not too much. Mostly along team boundaries.