Before I go further, I want to clarify that I love GraphQL as a frontend engineer. It empowers me to create.

I also think GraphQL is a great choice for larger engineering organizations. Having a GraphQL server as an API layer over different micro services allows frontend engineers to just build without dealing with the complexity.

For new projects, however, I will no longer be using GraphQL. My definition of a new project is a project without a clear market fit and a project with a small team (less than 3 engineers).

Performance

As a backend engineer, I hate GraphQL. GraphQL provides a lot of flexibility on the client side but this means that we cannot optimize as aggressively on the server.

Making sure that our GraphQL server is performant requires discipline and care. It's questionable if this investment is justified unless the team is already well versed in GraphQL performance. For example the team will need to know how to utilize dataloaders to avoid n + 1 queries.

Security

With a traditional REST API, we can add security on each of the routes that we are exposing. With a GraphQL API we have to be cognizant of the fact that there could be endless permutations of queries that can be triggered.

Types and access to types have to be organized with care. We have to make sure that we don't unexpectedly add a subquery that exposes sensitive fields.

Engineer Onboarding

GraphQL is new to a lot of engineers. Traditional REST API is familiar to many engineers. It's one extra thing someone has to learn before they can be productive.

It's tempting to reach for GraphQL especially if we want to learn it, or because we really enjoy working with it. Before we reach for GraphQL, we should ask ourselves 'Is this tradeoff worth it early on in the project?'

Conclusion

There is an argument that we should just start off with GraphQL if that's ultimately where we want to get to once the project gets big. If there is a guarantee that the project will get big, then yes I agree.

However, if we aren't sure if our project is going to be a runaway success with 30+ engineers in a span of 6 months...I believe going the more traditional route will allow the team to be more nimble and add talent easier. Time is of the essence, GraphQL can be added later when the organization matures.