Author: Ben Teese

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.

In this post I am going to talk about a question that can save you a bunch of time and effort, but is sometimes neglected in the rush from problem to solution: “Who’s had this problem before?”...

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...

Out at Shine's various client sites, our teams often meet to discuss the pros and cons of various technical solutions. And in the past, there was one particular Shine manager who, if he was in attendance, would regularly pipe up and ask the question: what's the problem we're actually trying to solve?