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.
Oldest comments (76)
Agree. Or you have to keep some kind of SDK library between code and gql, that provides the developers with predefined GQL queries, optimized and limited to some extent, so the developers cannot go wild :)
I think it's more of there is not alot of tooling and "best practices" for GraphQL.
Like for me a gold standard for API will be either Twilio or Sendgrid or Salesforce but when it comes to endpoints made using graphql I have no idea.
I'm the founder of WunderGraph, we're setting the gold standard of how to run GraphQL in production. We focus on security and automation to give you the good parts of GraphQL without you having to take care of the tradeoffs: wundergraph.com/
I can confirm, WunderGraph is a game changer.
You'll never have to worry about creating GraphQL API again, everything is in the box. Composing your service using other existing API is also really easy.
Hey @jensneuse ! Seeing the title of this post, I immediately thought about Wundergraph.
It helped me remove lots of complexity from the project, such as Apollo server, type-graphql, and next-auth.
@jensneuse I love WunderGraph! Are you hiring? :)
Thank you! What exactly do you like about it?
On hiring, you can join our discord and we have a chat.
Hi Jens. Could you compare wundergraph to something like Postgraphile? The beauty of Postgraphile for our MVP project was the ability to get up and running quickly. The only friction we've had thus far with Postgraphile was un-plugging the default JWT authentication in favor of a session-based solution. We evaluated Hasura mid way through our project and just didn't think it brought much to the table at that point (Typescript gen would have been nice in a new project). As we scale our project and introduce additional integrations we are always looking for more scalable/performant solutions. Thanks!
This is a great question, thank you!
PostGraphile is an amazing framework, written by benjie, a really nice guy from the GraphQL community. PostGraphile is, as it says, an extensible high performance automatic GraphQL API for PostgreSQL. It's written in NodeJS and can be used as a standalone service or even as a library.
WunderGraph on the other hand is a suite of tools to make API practitioners highly productive. Our aim is to create the best developer experience for working with APIs. GraphQL is core to our solution but it's just a tool to accomplish our goals. PostgreSQL is also just one of the possible connectors. You can also use MySQL, SQL Server, SQLite, GraphQL, OpenAPI (REST) and Apollo Federation, with MongoDB, gRPC, SOAP and OData support coming soon. Additionally, we look at problems like authentication and solve them with an end to end approach. For example, you can plug in your own OpenID Connect provider, e.g. Auth0 or Keykloak, and WunderGraph not just generates the backend to handle the auth flow and protect your APIs but also generates a type safe client to initiate and end the login flow for the user. It's like Firebase but using your own custom DataSources, Authentication Providers, File Storage, etc.. We're not doing anything magically. What we do is make a lot of decisions for you so that you can focus on what really matters: Getting the business logic right and building a great User Experience. Everything else, the whole Middleware layer, is solved by WunderGraph.
So, to answer your question more specifically. You don't have to think about JWTs with WunderGraph. We offer a secure login flow out of the box, with CORS , and CSRF protection for mutations, using secure, http only, encrypted cookies. If this is not enough for your problem, we'll add another flow. E.g. we'll also be adding token based auth for non browser-based environments. But again, our goal is that you don't have to think about this middleware layer. You should be focusing on User Experience and Business logic. Everything else can be standardized and automated away.
Depends on the stack also, as there are quite some things like Hasura to make GraphQL easy. But if you can't use tools like that, it totally makes sense.
Hasura will solve your backend woes.
Have you tried Dgraph? It takes most all of the backend work out of GraphQL while providing a true graph database.
I'll take a look! I'm not sure if I would use a graph database for most of projects I'm working on.
I hate graphql... full stop.
The client side should never need be so intelligent about the data as is necessary with graphql. Its a terrible pattern imho.
There are many usecases where clients can benefit from the added flexibility. No single style of API will be perfect for every purpose, but making statements like that just makes you look a little narrow minded to be honest. Choose the right tool for the job, sometimes that's GraphQL, sometimes it gRPC, sometimes it's REST, and sometimes it's something altogether different.
I never suggested there was ever a single api style that's perfect for every purpose. But GraphQL is shit, and rarely the right solution for MOST use cases where it's mistakenly employed.
As for how open or narrow minded I am - conveniently, your opinion on it doesn't affect me whatsoever 👍
It's clearly not shit, many teams big and small have invested in it (ex: Facebook). Please back up your claims, and we can have a constructive conversation. :)
Valuable insight for me just starting a new project and somewhat unsure of what API style should we go. And yes the project is still in design phase.
I've implemented already GraphQL in a more mature project and it was really delightful not having to build multiple custom endpoints for different frontends. Mobile and web developers have been able so far to query and rarely they require just a new field.
Hating tech is just so childish.
Just to clarify I don't hate GraphQL! I said I love working with it as a frontend engineer but hate it as a backend engineer. It's not that I hate the technology, I hate it because it's much harder to optimize a graph vs. optimizing specific routes...makes my job a lot more difficult.
I've never considered GraphQL for large or serious projects. It always appeared to me a good fit for MVP or prototypes. That's just my view based on my experience. The "security" part in this post is one of the concerns that I never felt GraphQL would replace my REST API requirements. I know there are people who are building cool and serious stuffs with it, but for me, it's not yet for serious ones.
Out of curiosity, what are your security concerns that GraphQL is unable to cover?
Just the "Security" part the OP written in this part - that is: In a REST API, adding a number of middlware to a specific route is easy - which is not as easy in Graph as per my knowledge.
Dunno what tools you're using but for example laravel lighthouse has @can directive and all you have to do is place it on your schema or even field. lighthouse-php.com/master/api-refe...
I actually developed a middleware in PHP for GraphQL, that uses directives. I can define, as an example, a
@signeddirective that forces users to go through authentication middleware. Basically you can inject yourself to the parsing process and put your stuff in there. Many developers just don't wanna dig deeper into that and prefer using ready-to-use frameworks that do all the heavy lifting. I also implemented a directive for fields which hides them from introspection.But you're right, it's not easy to do and many libraries don't include something like this. GraphQL is very complex and the support for some languages is lacking.
This was my experience building a GraphQL API with Elixir + Postgres. Ran into all kinds of n+1 issues. Dgraph solved all these problems for me, it's allowed me to ship a scalable GraphQL backend with minimal effort as a team of one. Pretty incredible tech, I wrote a summary here: dev.to/koder/dgraph-is-the-most-ex...
So you don't want to control any logic in backend and just expose all your data with generated APIs? I just looked at DGraph and it seems like ready to go solutions to generate API from DB on the fly with auth.
Anybody out there tried Hasana no code SQL-2-GraphQL server?
betterprogramming.pub/create-a-gra...
What are the security failings specifically, that are inherently solved by a REST architecture? Can you elaborate? Most security concerns are solved by good infrastructure not the style of API you choose. If that's where your security is made or broken then you have bigger problems.