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.

[Mihai Radulescu]

If you have lots of experience with graphql... then why not? If you have 3 devs working in graphql for 3 years... switching them back to rest is nonsense... as this article thesis anyways..

[Daniel Lo Nigro]

Regarding security, ideally the security of your data should be enforced in your data layer (whatever technology you're using to load the data) rather than in your business layer, to ensure that access restrictions are consistently applied in every place the data is loaded. Applying permission policies just in individual REST or GraphQL endpoints is quite error-prone and it's likely you'll forget to apply them somewhere (eg in scripts that send emails to users, batch data processing jobs that summarise data for users, etc).

At Meta / Facebook we have the concept of a "viewer context" object which describes the currently logged-in user (user ID, etc), and this viewer context is mandatory to pass to all data loading calls. Each type of entity (eg. post, photo, comment etc) has a set of privacy rules that determine if the user can see it or not (eg. is the user a friend of the author if the post is set to friends only, is the user in the group if the post is in a private group, etc). This ensures the access restrictions are the same across everywhere that loads the days - GraphQL, GraphAPI, backend scripts, etc.

[vladi160]

It is just an ugly standard api implementation with 1 post endpoint . Even the graphql users don't know, why they are using it.

[John Peters]

As to the comments "don't start with microservices" I disagree totally. They only represent a fully decoupled endpoint, which is vertically and horizontally expandable (forever). The days of dedicated monolithic back ends is over.

[AlexSouz]

I totally agree 👍