Five Common Problems in GraphQL Apps (And How to Fix Them)

I’m talking about problems such as: - **Schema duplication** - **Server/client data mismatch** - **Superfluous database calls** - **Poor performance** - **Boilerplate overdose** I’m willing to bet your app suffers from at least one of them. Good news is, none of them are incurable! … ### Problem: Schema Duplication One of the first things you realize when coding a GraphQL back-end from scratch is that it involves a lot of similar-but-not-quite-identical code, especially when it comes to schemas. Namely, you need one schema for your database, and another one for your GraphQL endpoint. Not only is it frustrating to have to write more or less the same thing twice, but you now have two independent sources of truths that you need to constantly keep in sync. … ### Problem: Server/Client Data Mismatch As we’ve just seen, your database and GraphQL API will have different schemas, which translate into different document shapes. So while a `post` fresh out of the database will have a `userId` property, the same `post` as fetched through your API will instead have a `user` property. This means that getting a post author’s name on the client will look like: … This can be a problem anytime you’re trying to share code between client and server to simplify your codebase. And even beyond that, it means you’re missing out on GraphQL’s great approach to data querying on the server. I recently felt that pain when trying to build a system to generate weekly newsletters: each newsletter was composed of multiple posts and comments, along with info about their authors; in other words, a perfect use case for GraphQL. But this newsletter generation was happening on the *server*, meaning I didn’t have a way to query my GraphQL endpoint…But what about GraphQL? Assuming our posts have a `user` field with its own resolver, we still have one initial database call to get the list of posts. But we now have an extra call to fetch each user *per resolver*, for a total of **11** database calls! Now imagine that each post also has 5 comments, each of which has an author. Our number of calls has now ballooned to: … ### Problem: Poor Performance Even with Dataloader enabled, complex views can still trigger multiple database calls, which in turn can make for slow loading times. This can be frustrating: on one hand you want to take full advantage of GraphQL’s graph traversal features (“show me the authors of the comments of the author of the post of…” etc.). But on the other hand, you don’t want your app to become slow and unresponsive. … ### Problem: Boilerplate Overdose This is by no means an issue exclusive to GraphQL apps, but it’s true that they generally require you to write a lot of similar boilerplate code. Typically, adding a new model (e.g. `Comments`) to your app will involve the following steps: