Learning how to write a GraphQL server is one of the biggest challenges I've seen for those who are new to GraphQL. This is because it requires a change in mindset, especially if you are accustomed to writing REST servers. Specifically, instead of thinking in terms of implementing individual endpoints in isolation, you have to think in terms of implementing an entire GraphQL schema that can be queried in any way.

This need for flexibility can cause anxiety for some developers, especially when it comes to performance. To deal with these concerns, some developers panic and pre-emptively reduce the flexibility of their GraphQL schema to head-off anticipated issues. But in doing so, they start to negate the chief benefit of using GraphQL in the first place: being able to flexibility and efficiently access data over a network as slow and laggy as the internet. Taken to the extreme, developers can even end up in a situation where they're paying all of the additional cost of using GraphQL, but not reaping any of the benefits.

It's true that strictly speaking, the easiest way to write a GraphQL server isn't necessarily the most performant, especially in comparison to writing an equivalent REST server. This is part of the trade-off of using GraphQL. However, it's also true that the majority of the time, this performance difference won't be noticeable to the end user. Furthermore, even if it turns out that there is an actual performance problem, there are plenty of mechanisms available to deal with it, without compromising your schema.

In this post I'm going to show you an example of a common source of performance anxiety for GraphQL server developers, and how it can trick them into thinking that they're going to have to make adjustments to their schema to deal with it. I will then present an alternate approach that allows the best of both worlds - a performant solution and the simplest schema possible. In this case I'll be using Apollo Server to write the server. I'll be assuming you have some knowledge of both GraphQL and Apollo Server.

TGRS stands for TypeScript, GraphQL, React and serverless. Over the last couple of years we have successfully built a number of enterprise single-page applications (SPAs) using this stack of technologies, as they complement each other well. In this post I'll talk about what our motivations have been for choosing...