Why I no longer use GraphQL for new projects

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.

Comments

[tangkikodo]

for a small team & project, communicating through a flexible query layer will lost the efficiency.

rpc/restful is much better. The key problem is how to quickly and easily establish a API for new requirement, which combines all data together? like graphql did.

for example, just define a new schema, and then the lib will automatically resolve it.

with post_method to easily post-process it and create what frontend exactly expected and they need not to do any extra work at frontend.

async def batch_person_age_loader(names: List[str]):
    print(names)
    _map = {
        'kikodo': 21,
        'John': 14,
        '老王': 40,
    }
    return [_map.get(n) for n in names]

class Person(BaseModel):
    name: str

    age: int = 0
    def resolve_age(self, loader=LD(batch_person_age_loader)):
        return loader.load(self.name)

    is_adult: bool = False
    def post_is_adult(self):
        return self.age > 18

async def simple():
    people = [Person(name=n) for n in ['kikodo', 'John', '老王']]
    people = await Resolver().resolve(people)
    print(people)
    # query query kikodo,John,老王 (N+1 query fixed)
    # [Person(name='kikodo', age=21, is_adult=True), Person(name='John', age=14, is_adult=False), Person(name='老王', age=40, is_adult=True)]

I wrote a lib called pydantic-resolve to handle these stuff in python.

github.com/allmonday/pydantic-resolve

You can define schema like what you did in graphql query, and you have the ability to tweak the data of any layer which graphql is not capable of.

[Ilyas Karim]

Maybe you can try hasura.io/. It is so amazing,

[Coleman McFarland]

GraphQL is a bunch of people adopting Big Tech solutions prematurely and without merit. You don't have Facebook's problems. GraphQL causes more problems than it solves for most systems.

[a-tonchev]

I personally never saw/feel the need of Graph QL

[Raul Rodriguez]

Before I discover keystonejs.com I may have agree with you, but this backend framework is a game changer.

Just defining schemas (objects with field and types) automatically gives you a complete GraphqlAPI + Pretty CMS. All relationships are connected. It uses Prisma on its backgrund. Can let you extend and customize mutations, triiger actions on hooks, add layers of security. Authentication, authorization and caching included.

I can start a backend project in a couple of hours.

My favorite project in 10 years of developing as a backender

[Pulkit Kashyap]

Don't agree with the Engineer Onboarding part here. It is the part and parcel of being a software engineer.

[Azula]

Projects like Hasura can help with the N+1 query problem as it correctly converts the graphQL request to a single SQL (Postgres) query. It also uses Postgres' Row level security feature for authentication/security.

Agree with you on onboarding of new engineers as everyone is used to REST APIs. GraphQL shines when you have separate App/Web frontend teams and all teams can be much more productive by introducing GraphQL endpoints to shape the backend data in the way they like.

[Alexander B.K.]

What about gRPC ?

[Mr Vinny]

GraphQL queries could cause performance issues.
REST can do much of what GraphQL does.
GraphQL makes some tasks more complex.
It's easier to use a web cache with REST than with GraphQL.
The way GraphQL schemas work could be a problem.
REST is better for error handling and tooling. by yacinetv.fun/

[Sohail Iqbal]

GraphQL is just a tool, and we use it based on the use case at hand.