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 choic...
For further actions, you may consider blocking this person and/or reporting abuse
I'm sorry but your arguments are very poor.
The worst thing that can happen with any app (web, desktop, mobile, etc) is that due to bad backend design/architecture they should call multiple api requests to display some data it doesn't matter if it's REST API or Graphql.
Just think of if you order a notebook and in stead of receiving a whole notebook at once you'll get it in part first keyboard some time later display then other parts. For the user app is a complete product why user have to get parts of it? Of course there are some optimisation technics and data is loaded in parts but the reason why they were created in not just a poor internet connection. User would prefer any app to be loaded just when the app is opened and data is just there no loaders, no jumps, no weird behaviours.
Of course all these can be solved both with Rest API and Graphql but it requires
a little bit more work and better architecture design.
Performance (N+1 problem)
If you are using node.js there is a tool called prisma (prisma.io) it will help forget about any dataloader.
But keeping in mind that it would be better for user to get all the data for current view at once some problem may occur with Rest API so you'll have to find solution for that.
A lot of modern backend frameworks doesn't solve n+1 problem.
If your are using Rest API it doesn't mean that your backend has better performance. Users don't pay for your backend and it's performance they pay for the data/information they see on their displays, they don't care about your backend and if it has n+1 problem or not. And it's a huge difference when the app has to make 10 http request, wait for them all then app code should somehow merge them and display meanwhile it can be done with just one http request.
Security
Very similar thing can be done even with Graphql. You can secure each query or mutation as you can secure each endpoint when you're using Rest API. It's just a question of architecture and your comfort zone.
If someone doesn't have deep understanding how current tool works that tool won't be helpful. Any tool can be misused. There are no bad or good tools, there are tools that solve specific problem and maybe there are not trying to solve your problem, so developers should choose tool according to their problem.
I'm talking about a special kind of app, a project that's just getting started.
The worst thing that can happen to a new project is no one uses it. I believe the main problem at hand is validating a business idea, not worrying about sending 5 requests instead of 1 request.
There are definitely ways to have performant and secure graph. It does require a level of comfort zone with GraphQL. It does require additional tooling. It might also introduce some black boxes as well if we are blindly using these tools without understanding the internals.
Choosing the right tool for the job is very important. We have to consider the stage of the product and the size of the team when choosing initial set of technologies.
If I'm working on a mature project that already has product market fit, of course I would prefer to work with GraphQL. These arguments would be poor if I was talking about mature apps.
To your point about reaching for a tool too early in a project, a microservices architecture shouldn't be utilized before the "seams" of the business domains have been clearly defined.
Absolutely. Microservices is not the right approach when we are just trying to validate a business idea.
Have you tried keystonejs.com?
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
I'd suggest hasura.io/.
I think that there is a world between REST and GraphQL.
For front-end application, there is a need to create something specific for the jobs (presenters). Most of us are not developing a Facebook that has the complexity of displaying lots of variable data.
In most application that I have worked on, we always ended up writing services (note that I'm not using the word REST) that were used to present data for specific parts of the application. Mutation were also tailored to the specific need.
The architecture was usually FE -> Presenters -> Business
Presenters are specific to the view (whether that is web, mobile, or mobile app).
This does not suite all but when the team is taught for defining the contract and making them evolve according to the need.
I don't think microservices, which is the nearest you could come to REST, have ever been suitable for frontend consumption especially for the reason
Unleash the trolls :-)
🤔 REST is not microservices, or nearest... Microservices is much more 🙌
In my company that i'm working at, we discovered that prisma sql query are poorly optimize...
We completely removed Prisma from the code and now we are writing our own queries.
This isn't quite right for a few reasons.
Agreed users don't care about n+1, unless that means things are slow to load. Then they care heaps.
GQL doesn't cache. Never will you get a 304.
GQL can't make use of client side service worker caching either.
It's not a huge difference if a Client makes 10 calls anymore because of multiplexing.. In fact if those 10 calls hit different pods/severs/dynos then the call is much faster. Each server has to grab a small optimised bit of data, where with GQL the fast bits of the query have to wait for the whole data to be built.
Lazy loading or partial loading of the data gives the user something to see while the rest is being load..
Now.. when you want to upload or download a file. How does GQL handle that. I've not been around all that long, but I always see people falling back to REST for these.
GQL is not great for errors. All posts return 200. If I say you got a 404 or a 401 or 403, then you don't have to think about what those mean. Each GQL build has to build its own error mechanic. Moving jobs means one has to learn new error paradigms.
Agree about how GQL handles security.. One can set limits right down to the field. In that it shines.
EDIT: I keep thinking of other things.. lIke debugging errors from the network tab.. Nothing like 20+ posts to the same endpoint to make finding the call that is returning an error a right pain. I'd take a RED line over a pile of 200's any day.
👎
I wanted to write some of these as well
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.
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.
@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.
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.
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.
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.
I work at StepZen, and because of the usefulness of our product I've really started to think in terms of GraphQL first, even when I daydream about personal projects. We offer advantages in terms of managing security and performance for you, which often is a first concern with larger teams, but I also find our custom directives make GraphQL accessible for 1-person projects because they complete elimate resolvers etc. I just write a little schema with directive that plug directly into my endpoints and I'm good to go.
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. :)
I like using graphql with highly related data structures. Hasura.io is pretty cool. What I don't like about graphql is the very verbose code when querying on the client side, and complex client libs like apollo.
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.
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'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.
As a FE engineer I like using it, because graphs reflect the way people think better. BE for graphql can be intimidating though, and the dev-time you save on the FE is shifted to the BE. That's the case when you implement the resolvers yourself, especially if you try to map to a relational model or tree structure. Neo4j have a project to map graphql to a graph database though, I'm tinkering with that now and it seems they're tackling some of the problems you mention. And it needs surprisingly little code: neo4j.com/developer/graphql/#_usin...
I'd like to hear other people's opinions / experiences, but it seems pretty useful at this point
Adding dataloader is not that hard, you just need to detect where you will need this. For example in a field resolver
In REST its true that we can protect routes using a middleware or something. but when you develop a large scale project involving multiple level authorizations, things started to get messy. For example take a route like
GET /api/invoice/1. There can be additional fields that are hidden or shown based on the user authorization level. Implementing this in REST is a mess, even though documenting it even harder...serialization goes the sameBut in GraphQL this is already solved, you can have granular field level authorization which is lot easier to implement and maintain.
So my conclusion is, if your API is getting complex, involving authorization levels, having multiple people working in different client applications...GraphQL worth the shot. It may take some time, but once you get it going you will see the result
The new HTTP QUERY Method, is designed to compensate that.
It will be possible to use Rest as you use it now in elastic, so you can use it to get just some data, and to grab relational data too.
a good open source project that take already advantage of that is directus9.
RelationalData
Search Method
REST API as a concept has been known for nearly 20 years. The GraphQL specification was publicly released 6 years ago. There are tons of frameworks out there which already contain support for REST API implementation, in a variety of languages, with all sorts of features and helpful things for developers to start using it out of the box. We have it so easy when a framework converts those HTTP requests to a standardized request / response format, with easily implementable middleware per route and all sorts of cool gadgets to make it even better.
GraphQL doesn't really have this kind of ecosystem. At least not yet in the open source world (I think?). Commercial solutions might have some since they're motivated by money to produce them.
If GraphQL solved some specific problem we have, since most of us don't work at the level that Facebook operates in, people would be all over it. I'd bet there'd be tons of libraries out there that allowed users to write GraphQL schemas with custom directives for queries, mutations and fields with little effort, and middleware/some other security mechanism to protect those. So far I've had to implement all of those by hand, because there's very little support for mechanisms like those in languages like PHP.
We used GraphQL on a front-end rewrite project and it didn't take long for five developers to learn how it work. It's not that hard. When you explain to them what the n+1 problem is and how you can solve it by deferring resolving to a later stage when you have all the necessary data to perform a batched query or something, it's relatively simple to use.
Unfortunately, who likes implementing that extra layer of complexity to a project without any significant performance increase (mobile devices?) when you're not Facebook? I personally like GraphQL, because it gives me type safety and a pre-defined schema for my API. That's quite good in languages like JavaScript or PHP. I don't really like writing an OpenAPI spec schema 'just as an extra'.
The security argument doesnt sound valid. You have todo security in any case, preferrably at database level. Any use, test, graphql or even SQL, will be subject to the same security. Bot rest backend and graphql backend should not implement any security. Databases do it better, faster and a lot more reliable.
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
I'm not sure that REST APIs make security any easier, unless they're incredibly simple responses with very little nesting (and if the data shapes are that simple, you wouldn't even need to consider GraphQL). As soon as you have any system of composing the fetching and formatting of data from different places (like many "serializer" libraries) you run the risk of a deeply nested bit of data not correctly checking the permissions of the top-level "viewer." That is a hard problem, but it affects both GraphQL and REST API with non-trivial data shapes.
I agree the security isn't any easier, but there's more resources/best practices around REST APIs than GraphQL. Without understanding GraphQL, someone could introduce a leak by adding an additional property to a type that's part of a bigger query.
That's just as easy to do in a REST API with something like Django REST framework Serializers. Those can be nested arbitrary, and when you're adding a field to one serializer you have no way of knowing all the places where that field might appear deeply nested from some other serializer (without just manually checking all of your serializers). Of course, you can prevent this problem with stronger conventions or tools, but in my experience those conventions and tooling are no better for REST APIs than they are for GraphQL.
Good point! Maybe the better argument is that it might be easier to secure a REST API since there are more resources, best practices, and more engineers with experience. With GraphQL, there's just so many new things to worry about as well (i.e. hiding parts of the graph from the public).
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/
This is a good article, I don't know that I 100% agree with the sentiment but maybe 70%.
More often than not, a REST API is perfectly fine. But there are occasions when graphql will save you an absurd amount of development time.
I built a CRM for the lending industry and the clients had massive databases with hundreds of thousands of records that they needed to query based on insane amounts of data. They may want to find all of the men in Louisiana who are between age 30 and 50, that are currently employed, making over $50k per year, and have an active cell phone. These people may need to be narrowed down by people who owe capital one more than $1000.
Considering that there are about 80 more data points that they might want to search, this type of architecture will take weeks to build out as a REST API or minutes with Hasura.
But at the same time, queries that complex are usually the exception, not the rule with most of the projects that I work on at least.
REST is standardized, familiar, and perfectly sufficient for most use cases.
I've used graphql on small projects and I've used rust apis and large projects, I have a really hard time using any definitive language but graphql was definitely driven by hype for far too long.
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.
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.
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.
I've been aware of GraphQL for some time now and outside of tinkering in a Gatsby-included console, I have not used it in anger. I did like the idea of specifying the shape of returned data and combining back-end data.
I'm now thinking of one-manning some dev ideas I have, using Typescript via ReactJS, React-Native and possibly a NestJS back-end. I only needed to read as far as 'authorisation on REST end-points' coupling this with prior knowledge of my domain, AND being a small team of one, I've realised that I do NOT need something else to 'figure out', I'm too old for that, too 😏.
So, in short, your article was timely and really has made a decision for me, I thank you.
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.
Lack of strong points, all the arguments here indicate you simply don’t know how to implement a proper GraphQL backend, with all the resources online, and I doubt things will get better for you for REST API… the reality is cruel but true…
There's definitely more resources + best practices for REST API than GraphQL. I'm arguing that at the beginning of the project, it's not worth investing in the additional tooling and introducing the additional friction when onboarding engineers who have not worked with GraphQL.
The only true challenge here is the learning curve. Other than that there are no excuses.
Graphql works great in both MVPs and large production apps.
But then the question of should you spend the time on the curve..
Show me how to upload an image (not base64 string) in GQL.. My user wants an avatar. They also want to download a PDF.
When a PFD file doesn't exist for the user, whats the error look like?
In 3 words or less describe the error for a missing PDF in graphQL
In REST.. it's "you get 404"
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.
If the project has a disconnected front end from the get go then I would definitely use graphql from the start.
A rest API is a bad fit for js framework frontends. In fact js frameworks are a bad fit for web projects in general, but that is a whole other discussion. 😂
If your web app is rendered server side, there is no need for an API or GRAPHQL at the start.
Using django + htmx + alpinejs you can create a pwa that competes with the best.
Later you can add DRF , graphene. graphene will generate graphql from DRF or django forms.
A good example of a project that was great until it was rewritten as a disconnected js framework (react) with graphql. Is saleor by miramee.
2 years after they started the conversion it is still a pile.
If they spent the resources on improving the django app (that already worked) it would be a great product without bouncing balls or cutesy thing to cover up how slow it is.
Why is it that server-side apps don't need cutesy gadgets to amuse you while you wait?
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.
I wrote a lib called
pydantic-resolveto 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.
It's really a question of what stack gets the responsibility for organizing an operation. If it's the front-end then yes, GraphQL is the proper choice. But I've found it places unnecessary burden on front-end, and extra work on the service that would otherwise be better spent in other areas. Allowing front-end engineers to work on REST API is the obvious solution. Breaking down walls and instilling confidence in our engineers is key to success, IMO. Nice article.
Two words, one product: Postgraphile.
Work smarter, not harder.
I totally agree 👍
GraphQL is just a tool, and we use it based on the use case at hand.
Maybe you can try hasura.io/. It is so amazing,
What about gRPC ?
Don't agree with the Engineer Onboarding part here. It is the part and parcel of being a software engineer.
I can't imagine using graphql for every single new project. Why would it be a requirement? Every job and project is different with varying time and resource constraints.
Anybody out there tried Hasana no code SQL-2-GraphQL server?
betterprogramming.pub/create-a-gra...
I personally never saw/feel the need of Graph QL
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.
It is just an ugly standard api implementation with 1 post endpoint . Even the graphql users don't know, why they are using it.
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..