42 ms·

After 6 years, I'm over GraphQL

• davidw 2y ago
  I used it at a past place (didn't choose it) and IDK, it just seemed like one more layer that wasn't really buying us much. Wasn't a fan.
• shados 2y ago
  A lot of the points in the articles are issues anywhere, it just depends on how well they are understood in the context and how mature the tooling is. Eg: rate limiting in REST is rarely problematic because we have no end of WAFs and gateways and circuit breaker libraries that understand REST very well. It's very true that a few years ago the gap was there, and people implementing GQL had to solve all these problems without access to these mature solutions. But these days, they're mostly solved problems. Authorization by type that propagate through the graph is pretty simple. Rate limiting and complexity limits on queries is often built in the frameworks. Query parsing is solved with persisted query all the major frameworks have as first class citizen. Performance: lots of GQL caching solutions out there, and the "multi threaded by default" model used by most frameworks helps a lot. Etc etc etc. I jumped companies a lot, did both. For a while I too thought GQL was redundant, then went back to a more classic world after a successful GQL implementation. I had forgotten how many problems were solved, especially organizational and people communication issues, through GQL. And so we're moving to GQL again. Someone in the comment mentioned GQL is a tech solution for an organizational problem. I'll say most good software tooling and frameworks ARE tech solutions for org problem, because technology is usually a solution to people problem. GQL is the peek of that, and it does it quite well. Don't use GQL to solve tech problems, there's better tools for those.
• rezy_root 2y ago
  If anyone is reading this and is using Django there is a smooth transition to drf-flex-fields. The package gives GraphQL-like features while using REST. - https://github.com/rsinger86/drf-flex-fields https://github.com/rsinger86/drf-flex-fields - https://django.wtf/blog/graphql-like-features-in-django-rest-framework/ https://django.wtf/blog/graphql-like-features-in-django-rest...
• sk10y 2y ago
  As much as I opposed GeaphQL at first I found a use case for it and have been using it successfully for past 4 years. In my application GraphQL is just a layer on top of GRPC API. It helps to fetch data across different services and glue together different entities in one frontend friendly payload. Since GraphQL is essentially a proxy in front of GRPC (which is the real API, exposed over REST endpoints as an alternative to GraphQL) I haven't suffered from most of the issues described by author. Authorization is performed by GRPC which returns only fields available to the user, rate limiting is performed on GRPC requests so at some point your data will start coming partially if you make too many queries or query that is too complex, N+1 problem is still there, but in a distributed system it's there even without GraphQL, the mitigation is caching in GraphQL server on GRPC request level. In my experience GeaphQL really helped decouple frontend and backend and I'm pretty happy about it. Besides GraphQL offers some standard way of making server side event streaming, it's not supported that well, but at least it's more comprehensive than bare web sockets. I never got around to implement mutations though, individual change requests via REST are enough.
• zer00eyz 2y ago
  GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permissions interaction)... security is baked in to every field. 4. Because of permissions, and login requirement it's hard to be a bad actor (FB just locks you out, nothing is public). If you have a SPA and logged in user requirement and that robust permissions model then GraphQL might make sense... Otherwise its a shining example of conways law and might not be fit for your org... The same can be said for react too.
  • jamesrr39 2y ago
    presumably there is still some authorization requirements though? The logged in user is authorized to see details about Friend 123, but not about Non-Friend 456?
    • andrelaszlo 2y ago
      That might be what they meant by "robust permissions model".
  • UweSchmidt 2y ago
    What if Facebook wanted to open up parts of the site for users without an account, would that require a major reengineering? I've wondered why Facebook (and Instagram) are so strict about not showing anything to logged-out users, could technical reasons be part of that decision?
    • tomlong 2y ago
      I think this currently exists in some shape or other, I don’t have a facebook account but I can click on profiles of businesses and get their opening hours and pictures of their menus or whatever. In think there must be some stuff with a public context.
• oksteven 2y ago
  GraphQL was the shiny new thing that everyone was excited about and I was also trying to learn and use it too, but I've never found a compelling use-case to use it over REST API. Now that you shared your experiences with it, it give me more reason to stay away from it. Plus, I think it's more productive to stay with the stack I'm very fluent at.
  • gbnvc 2y ago
    [dead]
• aurareturn 2y ago
  I never got into GraphQL. It always felt like a lot of complexity for little gain (I'm full-stack). People always jump on tools created by tech giants but they solve different problems than the vast majority of companies.
  • oksteven 2y ago
    agree, it solve problem at FB for sure, that is a good point.
    • romanovcode 2y ago
      Same with Redux. Solved problem in FB. Increases complexity tremendously for 90% of other websites. I remember seeing the tutorial being showed in Todo app and thinking "wtf is this garbage needed for here". I'm glad Redux hype train is over and nobody is using it on new projects no more.
      • dgb23 2y ago
        I think the hype is mostly over because of useReducer. It's the simplest thing that lets you structure your code in the way you want if you'd had chosen Redux (or similar).
        • aurareturn 2y ago
          I’ve also switched to using useReducer.
      • hot_gril 2y ago
        If it takes more than a minute to understand how a single button example works, one should give up. Maybe some day I'll come crawling back to Redux, that'll be fine, but so far it hasn't happened. Same with Angular.
        • romanovcode 2y ago
          I think Angular fits very well for certain public, that public being Java and .NET developers. Extremely similar concepts. For rest, yes, it's a disaster.
• BillyTheKing 2y ago
  GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api as a whole quite annoying. I do really like the Api definition part of it though - but I found something like typespec now to be the perfect middle-ground, it allows out you describe your apis similar to a graphql Api without enforcing the graphql engine on you though.
  • manquer 2y ago
    Hasura does role based access control pretty well. Apollo federation and implementation of supergraph and nested graphs is pretty robust We use both in production at reasonable scale and complexity 10+ roles few hundred object models, 100s of request/sec
  • tisdadd 2y ago
    I remember having to solve the merge in the past and we ended up using a merging tool pretty easily to do so. Believe it was this one? https://the-guild.dev/graphql/tools/docs/schema-merging https://the-guild.dev/graphql/tools/docs/schema-merging We were basically just enhancing an external graph with some of our own stuff added on though so fairly straightforward.
  • kabes 2y ago
    True, but rest calls over multiple micro services is even worse
• jamesrr39 2y ago
  I agree with the article, and want to add on that the browser network debugging tools are a pain to use with GraphQL (every request to /api/graphql, can't even quickly filter by endpoint name). I landed instead on OpenAPI, which can feel like a bit of a hoop to jump through sometimes when writing endpoints (but then, so can GraphQL), but the result is equally nice. And it's much easier to get authorization right with REST APIs. I wonder if GraphQL would have been as popular if it was a much smaller shop than facebook launching it. Feels like having a name like FB gets you a tech credibility pass.
  • RedShift1 2y ago
    For the browser network debugging tools: I'm using the Apollo GraphQL client and added a link that adds the operation name into the URL. So my URLs look something like "/graphql?op=getStuff" and my GraphQL queries: "query getStuff { ... }"
  • silentguy 2y ago
    There are browser extensions which make it easier to debug grapgql. A new pane is added to the browser debug panel. Last I used them more than two years ago, it was still not as good as the built-in network tab for rest queries. Still better than the default for the graphql queries.
• noduerme 2y ago
  Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.
  • manquer 2y ago
    Graph models need not be your tables . They should reflect your data models, the same kind of models that would have been exposed in a traditional RESTful API? Similar concepts of allowing queries and response formats was there in other standards and not new ? OData is fairly popular in REST world , even older , SOAP XMl had supported with custom query language one robust one I remember T-SQL used in Taleo the old Oracle hiring software There are many examples of clients doing joins and queries in other standards , it is hardly unique to GraphQL
  • rockyj 2y ago
    Not a fan of GraphQL (the problems mentioned in the post are very real), but GraphQL specification does not say anything about the DB design / queries. It is still an API layer and you are free to model it in any way you want.
    • discreteevent 2y ago
      Indeed, from one of the authors of graphQL on this very forum: "That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1] "GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2] [1] https://news.ycombinator.com/item?id=9879870 https://news.ycombinator.com/item?id=9879870 [2] https://news.ycombinator.com/item?id=14351800 https://news.ycombinator.com/item?id=14351800
      • dventimi 2y ago
        I do not share that author's belief about application code.
  • 2y ago
• santiagobasulto 2y ago
  Fully agree with the article. I think the summary is that GraphQL was a great idea from the frontend's perspective, but it was never fully worked out from a backend's standpoint.
  • dventimi 2y ago
    Hasura, PostGraphile, and Prisma do make it quite a bit easier for the backend.
• k__ 2y ago
  A few weeks ago, I read that tRPC is an interesting alternative.
  • welder 2y ago
    I've been using tRPC for 6+ months on a large web and mobile project with great results. The only downside is you're restricted to using TypeScript on both frontend and backend, but I was already going to do that anyway. Another library to check out: Drizzle-ORM
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• thom 2y ago
  GraphQL always felt to me like it solved the easy part of the problem and offered nothing to solve the hard part. I have a similar response to things like Zanzibar. At the end of the day I want to go and get some stuff out of a database, and that complexity just ends up dominating everything.
  • ozim 2y ago
    That is for me gut feeling about AI .. but that is not discussion about that topic. So in general had the same feeling about graphQL because I still had to write layer of code that gets stuff from database, get it limited or paginated. Maybe once you have enough endpoints then you can change your front end against already existing GraphQL - but for me that was never the case as 90% of work is adding new tables, new endpoints so graphQL feels like additional work with additional footguns for almost no benefits.
• david_draco 2y ago
  There was a very short window of time when you could make very advanced queries over your Facebook friends graph. It was awesome.
  • simonw 2y ago
    Yeah, those were quite something: https://www.tumblr.com/actualfacebookgraphsearches https://www.tumblr.com/actualfacebookgraphsearches
• jojobas 2y ago
  It's not graph, and it's not QL.
  • dventimi 2y ago
    It is QL.
• atsjie 2y ago
  Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time debugging, this is true for any codebase. But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of "learning-on-the-go" with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages). Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere. RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.
  • DanielHB 2y ago
    GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a human problems than a technical problems, if someone think there is no value in that and bare metal performance is paramount that person never worked in a big org. > RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. Unfortunately GraphQL way of working is very different from normal REST APIs and often requires more complex server-side caching. The N+1 problem needs to be figured out upfront for every data-storage system used in the backend.
    • dudeinjapan 2y ago
      Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contract--can do it with OpenAPI/Swagger--here are the endpoints, here are the allowed parameters, here is the response you will get--and we will make sure this narrowly defined scope works 100% of the time!
• lpapez 2y ago
  Kudos to the author for reevaluating his opinion and changing heart on a technology he admits to have championed before. IMO GraphQL is a technological dead end in much the same way as Mongo is. They were both conceived to solve a perceived problem with tools widely adopted at the time, but ended up with something which is even worse, while the tools they were trying to replace rapidly matured and improved. Today OpenAPI REST and Postgres are rightfully considered as the defaults, you even have PostgREST combining them, while most of those who adopted Mongo or GraphQL have either long migrated or are stuck discussing migrations.
  • FrustratedMonky 2y ago
    Curious, I hadn't heard that take on Mongo. Do you have a link to some more info on this.
    • sswaner 2y ago
      https://youtu.be/b2F-DItXtZs?si=rxrMwJVu95WQQt7M https://youtu.be/b2F-DItXtZs?si=rxrMwJVu95WQQt7M
      • FrustratedMonky 2y ago
        That is pretty funny, But that video is 11 years old. It can't still be like that? can it? Seems like people are down on Mongo in the last year, and I'm trying to catch up.
        • mst 2y ago
          WiredTiger was kinda Mongo's InnoDB and has made "your data will actually still be there later" rather more true than it used to be. I think the key thing is that people using MySQL were having trouble with deep data and found MongoDB's document oriented approach much easier, but these days people are tending to start with PostgreSQL, which can handle that nicely. (MySQL/MariaDB are far better than they used to be as well, though I find most stuff I read online doesn't take advantage of that as much as it might) There's also probably a factor of Mongo solving pain points people had when they switched to it, and there being lots of excitement around that, where today the same people have run into the pain points of Mongo often enough that it's no longer nearly so exciting a prospect. I wouldn't honestly be surprised if we're now at a point where people are -more- negative about Mongo than it really deserves, and I say that as somebody who viscerally hated it on sight and would still rather avoid dealing with it myself it if at all possible. (oh and MongoDB the -company- has always done their best to be a good corporate community citizen, sponsoring all sorts of cool things as a result, and while I think the license change was a shame I -still- think they're doing their best, just in an environment where they wouldn't have a best to try to do in the first place if they didn't avoid being killed by AWS)
• purge 2y ago
  many of these concerns are mitigated by ensuring you are using trusted documents (https://benjie.dev/graphql/trusted-documents https://benjie.dev/graphql/trusted-documents)
  • julian37 2y ago
    This. For graphql-ruby: https://graphql-ruby.org/operation_store/overview https://graphql-ruby.org/operation_store/overview
  • pjfii 2y ago
    Yeah, we use Hot Chocolate with .NET where it is called Persisted Queries. https://chillicream.com/docs/hotchocolate/v13/security https://chillicream.com/docs/hotchocolate/v13/security Honestly most of the "problems" the OP discusses has solutions in the documentation.
  • mst 2y ago
    Seems like at that point exposing each query as an OpenAPI endpoint would achieve pretty much the same thing. Then again having GraphQL as the definition for them is probably still not bad, I'll just have to write something that converts them to SQL::Abstract 2 trees once I get around to porting it to TS.
    • dventimi 2y ago
      It would be the same thing except with Benje's approach, you're basically using GraphQL as a developer tool to create those end points instead of writing code to do it. And you don't have to write something to convert them to SQL if you're using PostgreSQL, because Benje's already written it for you.
      • mst 2y ago
        postgraphile does look like it'll handle basic cases pretty nicely but I've gone through the docs and didn't find anything like an explanation of what SQL queries it ends up mapping to - do you happen to know if there's one I missed, or a list of examples of GraphQL + corresponding SQL, or something?
• RedShift1 2y ago
  I still love GraphQL, but much of the love comes from using tools like PostGraphile which generates the API for you based on your database schema. I then add my own Javascript plugins as necessary. Going back to REST and hand writing everything gives me the shivers, how much time am I spending just translating data A to data B? Authorization: I do it in the database using roles, row level security and column level security. It works well and I defer everything to PostgreSQL's security controls, it feels like the right place to do it and I don't have to worry about it going out of fashion, PostgreSQL is here to stay. Anybody else who talks to the database directly is also subject to the same authorization rules, which is nice. Introspection: this should really be disabled on production services. Only enable it for development. N+1 problem: I don't really have a problem with N+1 because PostGraphile converts the request into an efficient query. In other cases this problem presents itself in REST too and the article proposes hoisting N+1 queries to the controller, but that's just really moving the problem around, and you can do this with GraphQL too. The other problems, yeah sure they are present and a worry if you're running some highly visible/very loaded public API.
  • gatvol 2y ago
    If you're writing you're REST API by hand I'd suggest that you may not be doing it optimally.
    • toastercat 2y ago
      How should you write your REST API?
  • doctor_eval 2y ago
    Agree with this 100%, Postgraphile is awesome. I started a new project recently and was writing “REST” APIs because I’d been reading that people were put off by GraphQL, but it was a complete pain - instead of exposing my data and querying it as needed, I had to try to guess up front what I should expose in what object. It was the bad old days all over again, writing adhoc code on the server to meet the needs of the client… switching back to GraphQL - and postgraphile - was a relief. As someone who has used GeaphQL extensively, I really don’t understand most of the complaints, which seem like they’d be common to any complex API surface. Sure you can write a query that triggers a server bug, but that happens with REST too. Yes, your server needs to be hardened against these queries… so what? And security is hard, granular security doubly so. If you need to do field level authorisation then the problem is that you need a policy engine, not a different query technology.
• Aeolun 2y ago
  Can only agree with author on all points. GraphQL was nice for the types, and precious little else. But we have better solutions utilizing just the types now, so it was still valuable.
  • etimberg 2y ago
    IMO even the types are annoying because null is opt-out rather than opt-in
    • DanielHB 2y ago
      The reason it is like that is because GraphQL is intended for highly distributed backend where at any time one of those backend services might be unavailable and failing the whole request when only a single deeply nested field is missing would lead to bad user experience. In short GraphQL is optimized for keeping as much functionality working as possible no matter how much instability there is in the backend. This is a common problem in REST endpoints that consume data from multiple services as well. But the request usually fails completely. On the other hand REST request don't usually touch as many services as a GraphQL request.
• nesarkvechnep 2y ago
  Whenever you see REST in the article, think RPC. The author even says REST is simpler than GraphQL but I suspect they hadn’t implemented a REST API… ever.
  • 9dev 2y ago
    What is that you find so complex about RESTful APIs?
    • k__ 2y ago
      I assume, it's less about the complexity and more about most people not understanding REST.
    • DanielHB 2y ago
      Pure REST API is a huge pain in the ass to use and leads to bad performance because of waterfall requests. It is like the number one thing GraphQL solves for most people, decide which nested relationships to inline into a response. The simplicity makes it bad to use, if you work around the simplicity (arbitrary inlining, extra fields to choose what to inline, etc) then you end up with non-standard complexity.
      • nesarkvechnep 2y ago
        Bad performance if you haven’t heard about HTTP caching. REST implies cacheabality.
  • baq 2y ago
    I’ve done it once in my two decades of being paid to code and only because it was small enough to not impact any timelines… nobody cared anyway. Otherwise REST now means ‘RPC over HTTP with JSON marshaling’ for better or worse.
• SantiagoElf 2y ago
  Never bothered to learn GraphQL - anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects. Stick to tried and true - monolith, asp.net, angular or blazor front-end, relational database.
  • doctor_eval 2y ago
    > anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects. > asp.net, angular or blazor front-end Since when are these not technologies pushed by big tech companies? A company I worked with got badly burned by AngularJS.
    • SantiagoElf 2y ago
      I have used Angular since version 5. I have never had any major issues or problems with it. Think of it this way: GraphQL, Docker, and Kubernetes solve problems that very, very, very few GIANT tech companies have, but not every app will scale to millions of users.
      • doctor_eval 2y ago
        So you’re not familiar with AngularJS, the incompatible version 1? Angular 2 was effectively a complete rewrite - cleverly using the same name, thereby making it even more difficult for us - and the rewrite was done because Google Decided. Never again will I trust a Google front end library. Because of my experience, I feel that your position is making a slim distinction based on your preferences. All the tech you use is built for big corporations, why pick on one set of tech just because you don’t have the specific problems it solves? For me, for example, K8s properly solves a bunch of problems for my small SaaS business, not least of which is that I can upgrade my three piddly servers without taking my customers offline. My SSL certs get upgraded automatically without downtime. My CICD pipeline is simple. Logging is much easier. And so on. I don’t understand the disdain for modern, managed K8s at all.
• graemep 2y ago
  I would have thought all of those were fairly obvious. It is more complex and gives the client a lot more power and control, so the trade-off is inevitable.
• donatj 2y ago
  For the service I primarily work on, we've stuck firmly with REST for our internal APIs despite some mild pressure from elsewhere in the company to move to GraphQL. I personally believe it's been the right choice. Not only would it be probably an order of magnitude more complicated to setup and maintain, our REST APIs already are very performant. We've got little to gain, and the lack of flexibility from our POV is a relatively good thing. It gives us direct insight into desired use cases, and since the APIs are internal it lets us provide guidance on potentially better ways of implementing things as well as in some cases being able to provide direct optimizations for specific tasks.
• PaulHoule 2y ago
  When I saw GraphQL I immediately saw the issues that the poster talks about. I was amazed that people were drawn to it like a moth to a flame.
  • vvpan 2y ago
    I have used it on multiple projects and liked it, the project are still going strong a couple of years after and are maintainable.
• cqqxo4zV46cp 2y ago
  So, TL;DR: if you want to exploit the flexibility offered by GraphQL, you need to pay for that with implantation complexity. I’ve never used GraphQL in my life yet can foresee the issues described in this post. If you try to retrofit GraphQL feature X, Y, or Z into your REST API, you’ll run into these exact same problems. If you stick with a classic REST API, you pay for that simplicity in other ways. Who here is on team “I have a plethora of use-specific endpoints”, and who here is on team “I built dynamic field selection and relationship traversal into API framework”? And, yeah. Dealing with N+1 database queries is loads easier if you constrain the potential pathways to the point that you can just hard-code your database optimisations instead of having to build a dynamic query optimiser. So you end up with a bunch of basic resource-mirror endpoints and then the N+1 database queries become N+1 HTTP requests. But hey, at least the requests are roughly equally expensive so you can simplify your rate limiting! As usual, it’s a question of trade offs, and it’s not the easy-path “you aren’t Facebook, so you don’t need it!” that people throw around here on the reg’. And, certainly, those that look down their nose and say “I know that I was right to not care for this, bloody magpie developers and their shiny toys” are certainly speaking with a misplaced sense of superiority.
  • dventimi 2y ago
    Not necessarily. Tools like Hasura, PostGraphile, and Prisma let you skip out without even having to pay with implementation complexity.
• jvans 2y ago
  Additional graph pain points I'd add: Reliability: * Not null fields in a distributed system are a lie. Clients write code assuming something is not null, so a query that fetches data from N sub systems breaks the entire page when one of them fails. Performance: * People say you only need to fetch just what the page wants but in practice clients create re-usable fragments for every object in the system and use it everywhere. Any time a new field is added, every api call fetches that new field adding latency everywhere * clients are unaware of the underlying topology and add fields that are usually harmless but have bad tail latencies. * The completely generic nature of the API means the backend can't optimize performance for a specific page. E.g. if one API has nasty tails, but it's not that important for this page, the backend could time it out at some reasonable value instead of holding up the entire request
  • RedShift1 2y ago
    * Not null fields in a distributed system are a lie If something is null that's not supposed to be null, then the entire operation should be called into question. It's probably not safe to proceed so it's a good thing he entire page breaks, you don't want users to continue based on wrong information. If you define something in the schema that it's possible that it's null, but then the frontend dev ignores the fact that it can be null, why is it GraphQL's fault then that the page breaks? * clients create re-usable fragments for every object As a frontend developer I don't know why you would do that, but if your frontend devs are doing that then yes they are doing it wrong... However switching to REST with statically defined endpoints doesn't solve the over/underfetching problem, but as backend developer you do get to gatekeep that aspect. So yeah the devs should really be just doing it right.
    • brabel 2y ago
      About nulls: you're right, but because of authorization, everything can be null - if you don't have access to something, we need to remove it from the result (instead of just throwing an error, as you may still get enough information to do what you need to do) - and that will always be a fetcher error in GraphQL if the field was non-nullable. And because you shouldn't really know or care beforehand which fields may be "hidden" from the end user due to authorization, you need to make everything nullable or risk making a breaking change later.
• quonn 2y ago
  GraphQL is a great choice for internal applications hidden behind strong authentication that do not need to be heavily cached and where things like DoS are less of a concern or no concern at all. It is often a poor choice for websites that should be cached, are publicly accessible and have simple and predictable data access patterns. GraphQL has a fairly flat but very long learning curve which makes it a power tool that is great for those who have learned it in depth. Without that experience one is almost always better off using REST.
• dudeinjapan 2y ago
  I was over GraphQL the moment I looked at the specification.
• pjmlp 2y ago
  Unfortunately it has become fashionable in SaaS products to only offer GraphQL endpoints, thus whatever we think about it, GraphQL it is.
  • williamdclt 2y ago
    I don't interact with that many SaaS products, but I've never seen that
    • pjmlp 2y ago
      If you want to be pedantic, some do offer REST or GROQ as well, which aren't much of an alternative anyway.
      • williamdclt 2y ago
        how is that pedantic? I assumed you were complaining about SaaS not offering REST (I don't even know what GROQ is) but it seems you're not okay with it either: what would you want then?
• jakubmazanec 2y ago
  For web apps (not simple pages), developed by a single full-stack developer, I think the best solution currently is to use Remix's loaders + actions (i.e. no need to create separate API layer) with EdgeDB (EdgeQL is like GraphQL but with capabilities of SQL, and the DB itself has authn+authz baked-in).
  • Kabootit 2y ago
    Agree! Came here to give props to EdgeDB. Completely removes the API layer if used with something like SvelteKit. Everything defined in their schema language which then generates typed clients for you. In my experience the use case is not limited to a single full-stack developer - this approach has turned our entire polyglot team into full-stack devs — no one is afraid of the data layer now. Super refreshing. For public facing endpoints, "exposing an OpenAPI 3.0+ compliant JSON REST API" would be the first thing I'd reach for.
• tarkin2 2y ago
  I heard the argument that it's good because you don't need the server devs to change the backend; you can specify the data you want. As echo'd before, I guess that's great if your frontend and backend can't be developed in sync. Overall, I'd rather improve the development synchronisation/modification problem between backend and frontend than drive the GraphQL tank through the codebase. I guess I'll need to wait another 6 years before I can avoid GraphQL. Marketing-driven fads: exciting at the start of my career, a painful chore now
• eterps 2y ago
  > Data fetching and the N+1 problem > [...] if a field resolver hits an external data source such as a DB or HTTP API, and > it is nested in a list containing N items, it will do those calls N times Why is this considered a problem regardless of the situation at hand? F.e. using REST, if the nested list contains on average N-2 items that can be efficiently cached, wouldn't that be better than having the cache constantly invalidated on the aggregation of the parent and its items?
• 0-bad-secrotrs 2y ago
  Aside from all the valid points listed in the blog I found out that the frontend engineers in my company save some queries in central library and reuse them even if they don't need all the field returned by this array just to save themselves the time they spend writing queries so they are basically using GraphQL as REST at the end and now we have the worst of both worlds.
  • brabel 2y ago
    Our frontend team needs to show the whole thing every time (as the user sees and edits full resources in most cases), which means they MUST keep a full query representing the entire resource, and when we add stuff in the backend, they must also add those things in the frontend (as they cannot generate UI for new things in most occasions). GraphQL was really a mistake for us.
    • RedShift1 2y ago
      Why is this a problem? If you add fields on a REST endpoint, you're going to have to change the client too to deal with those new fields.
      • em-bee 2y ago
        depends. i'd be writing the client such that it just lists all the fields, and then add special handling for the fields that need it. when the backend adds new fields, they will just show up and i just need to fix the formatting. with graphql i'd have to ask for those new fields, and thus make changes in two places. and in addition the backend team has to tell the frontend team about the new fields (instead of letting the api speak for itself), making it easier to accidentally skip a field.
      • chasd00 2y ago
        If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?
• dgb23 2y ago
  One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar. Same problem with Prisma Model definitions and other such things. Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and programming concepts in order to generate, parse and make sense of your thing. Let me seamlessly write your language with the data structures I already know in my language if that's possible. Don't make it pretty, make it usable.
  • doctor_eval 2y ago
    What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?
    • Izkata 2y ago
      From https://graphql.org/learn/queries/ https://graphql.org/learn/queries/ This isn't even close to valid json: { empireHero: hero(episode: EMPIRE) { name } jediHero: hero(episode: JEDI) { name } }
      • mdaniel 2y ago
        and I strongly agree with GP because those arguments <https://graphql.org/learn/schema/#arguments https://graphql.org/learn/schema/#arguments> can get to be insaneo with anything other than simplistic "episode: EMPIRE"; I regrettably can't link directly to it but https://docs.github.com/en/graphql/reference/objects#:~:text=A%20list%20of%20issues%20that%20have%20been%20opened https://docs.github.com/en/graphql/reference/objects#:~:text... shows that stuff can start to be more than the interior field selection, to say nothing of schemas that define complex typed arguments e.g. type Starship { id: ID! name: String! } type CaptainQuery { captains(starshipFilter: [Starship!]): [Starship] } # leading to { captains(starshipFilter: [{name: "Alpha"},{id: "cafebabe"}]) { id } } which I recognize is most often fixed via variables but when the hello-world examples call it out, something has gone awry https://docs.github.com/en/graphql/guides/forming-calls-with-graphql#:~:text=the%20syntax%20can%20get%20unwieldy https://docs.github.com/en/graphql/guides/forming-calls-with...
• vinnymac 2y ago
  I still enjoy using GraphQL, because it has allowed my teams to move measurably faster when developing APIs over the last half-decade. Some organizations seem fairly allergic to full stack development, but it has broken that barrier in ways I hadn’t witnessed before at my workplace. However, lately I’ve been thinking that with the advent of React Server Components we will see a migration away from GraphQL-focused Frontend applications, and instead move toward other solutions. Such as ones based purely on exposing Postgres databases (e.g. supabase & postgREST) and type safe APIs (e.g. tRPC).
• bluehatbrit 2y ago
  I've had the "pleasure" (/s) of inheriting a pretty large GraphQL API which I've had to maintain for the past few years. I've gone through the process of the hype, and then the sheer frustration. I'm now at the point where I think most people are just using it in the wrong places. GraphQL works pretty well when it's acting as a Backend-For-Frontend. The client can make a single call to get everything it needs at once, the BFF can then fan out to various microservices as needed. The frustrating part is when it's blindly used for something like a monolithic CRUD API with some light permissions. In that scenario you're taking all of the drawbacks, without reaping any of the benefits. I'm really glad to be leaving this project behind as I move jobs, and I'm praying no one suggests using it in my new job. At least not until the industry more broadly understands it in more depth.
• anonzzzies 2y ago
  Ah, this is the advantage I have waiting at least 10 years of everyone I care about whining I need to use a technology. I had a few years of people telling me about graphql and how it is the best etc, but they stopped after a bit and are doing rest endpoints again. So I never tried it even.
• __loam 2y ago
  Graphql was routinely an overly complex piece of shit when I was forced to deploy software with it.
• CharlieDigital 2y ago
  My $0.02 here: GraphQL makes sense only at a certain scale when you have multiple APIs built by multiple teams that need to be exposed as a single endpoint. GraphQL as an API or APIs is the perfect use case and the one that it was designed for. In every other case, REST is harder to do wrong and easier to do right. The tooling for it is widely supported and well known. Every aspect of building an easy to use, easy to own, easy to scale API is -- well -- just easier with REST. I have seen more than a few small, 4-8 person engineering teams reach for GraphQL and then wonder why every cycle starts feeling slow. In a 4-8 person team, the devs are usually working full stack and if not, then they are working closely enough that having a highly flexible API layer servicing the front-end doesn't make any sense since it's either the same devs or they're one Slack ping away from getting the right shape from the backend in one simple `GET`. Like the author, I've found that the story with OpenAPI nowadays is really good. I have a short writeup here with .NET that shows hot re-generation of the API into a TypeScript definition that can be used with React, Vue, or your framework of choice: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-with-dotnet7-webapis-typescript-openapi/ https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit... This workflow is super productive and perfect for small teams working full stack; far easier than getting GQL right.
• hakanderyal 2y ago
  Full blown GraphQL is hard to properly support. It needs a lot of developer time to get everything correct, as stated in the article. However, you can go very far with a simpler version of it, just by allowing clients to specify what fields/relations they want and in what context. I'm using a library that I've created for myself for years without any of the problems mentioned in the article. The client side queries are generated by the server at compile time. Each request for an object requires a "segment" to be specified. On the server, each segment has the necessary filters/limits automatically applied to prevent data leaks.
• oreoftw 2y ago
  Exposing bare GraphQL the right way can be challenging, totally agree with author on that. Using it on a small project also can be an overkill. But at the same time it doesn’t have to be that bad. I don’t have this array of issues because I do: - query whitelisting for performance and security, - data loading to avoid n+1, authentication with whatever works(session cookies, tokens), - permission check based on the auth context in a resolver. It works decently for us, allowing to stay away from getting into ESB. Yet have some shared domain, type safety, and easy integration of legacy and new systems/services. I would say a bigger issue for us was to keep it all nicely organized / designed in terms of types and api contracts. But that’s manageable.
• deleted 2y ago
  [deleted]
• probabletrain 2y ago
  What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits: - If data already exists in cache, a query will return that data instead of making a network request. - Everything that has a data dependency on something in the cache will automatically update when the data is updated, e.g. after a mutation. - Cache data can be optimistically updated before the request completes, UI that queries this data will automatically update. - Components will automatically refetch data if they need to, e.g. if an object is partially updated. The pain points are pretty painful though: - Really hard to debug unexpected refetches. - Normalizing the data for the cache comes at a cost, it can be pretty slow for big responses. - You quickly realise you need to really understand how the client works under the hood to be productive with debugging/complex behaviour. I see it as a case of "this is the worst API/client, except for all the others". I'm curious to hear how people using non-graphql APIs are managing data in the client in web-apps with complex data needs? [1] https://www.apollographql.com/docs/react/why-apollo https://www.apollographql.com/docs/react/why-apollo [2] https://relay.dev/ https://relay.dev/
  • travellingprog 2y ago
    TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overview https://tanstack.com/query/latest/docs/framework/react/overv...
    • romanhotsiy 2y ago
      We use https://tanstack.com/query/v3 https://tanstack.com/query/v3 + openapi-based auto-generated SDK. I would say the DX is pretty much comparable to using Apollo Client.
      • shepherdjerred 2y ago
        What do you use to generate your SDK?
    • 2y ago
• dzonga 2y ago
  when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems. There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firms etc. Some just use REST + JSON or RPC + JSON. Wish us an industry would read Joel's Spolsky's Fire and Motion article: While you're fighting tools built by FB you're not making stuff for your customers. Revenue / Profit >> Tech
  • yonixwm 2y ago
    That’s the problem. In the days of jQuery/Angular2 (and even now personally), React was a blessing. Everyone hoped the same here. We should just join technology a little later on the hype cycle and have less stress.
    • BiteCode_dev 2y ago
      React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason. That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time. I remember above all that: - React was hyped to the roof by facebook. They had a fantastic marketing machinery for that. - React sucked for years, with a terrible doc, a crippling webpack experience and breaking compact all the time. - The JS community was moving from koolaid to koolaid, never assessing the new tech for their cost. They solely inflicted on the world slow and brittle preprocessors left and right, thousands of stuff you had to integrate manually because "libs > frameworks", and jumped on react, redux, graphql, docker, spa, microservices. So I would say it was a loooot of hype for react, just like it was for graphql. I'm going to feel like spamming at this point, but, remember when XML was the future? https://www.bitecode.dev/p/hype-cycles https://www.bitecode.dev/p/hype-cycles
      • strken 2y ago
        XML was genuinely better than fix-width data formats (COBOL) or character-separated fields (CSV, HL7) for most APIs. Hierarchical deeply nested trees of data were the future. Everyone uses JSON or a more industrial format like protobuf/avro/BSON to represent such data now, but it wasn't necessarily wrong to point at XML and say it was an improvement.
• combiBean 2y ago
  I think the post is definitely mentioning a few valid points which need to be addressed in proper GraphQL API designs. But most of REST "solutions" over GraphQL considerations are just pushing issues from the server side to the client side. For example the whole n+1 data fetching topic: Yes this issue exists and like the author is mentioning: GraphQL has a well understood and common solution for this problem. On the other hand: In REST world you can have exactly the same issue, but either create a custom solution for this issue or push the issue to the client side, where this issue needs to be solved, too. I could not exactly follow the explanation of the special case of the n+1 problem in context of authorization. "This is actually trickier [...], because authorisation code is not alway run in a GraphQL context." OK authorisation code is not run in a GraphQL context, but why is this then a GraphQL issue? On the rate limiting issue I also do not see why these issue would by design just exist in GraphQL world: Yes you can have recursive data structures and write queries which can take a lot a processing time to resolve. But again: Why would the same recursive data structure not be possible to be modeled for a rest api and why would the same data not be queriable from a rest api? My guess again is: You _can_ model the same data structure and also _can_ query the same amount of data. And also again: In case of the rest api the complexity of querying this data is just pushed to the client side and that is why it seems easier to rate limit individual rest endpoints. But actually I see no reason why a GraphQL API could not rate limit e.g. on data loader or any expensive operation level, too. Generally regarding malicious (e.g. malformed) queries: I think this is definitely a valid issue, which should be addressed in GraphQL APIs. I think there should be a common way for application developers to sign their queries somehow and query engines should only attempt to process signed queries. This way only trusted developers are able to write arbitrary queries. On the "Authorisation" section I can not quite follow the reasoning. Aside from implementation-specific extra-calls to a presumed authorisation framework: Why would domain requirements be different when they are implemented either as REST API or as a GraphQL API? "Compare this to the REST world where [...] you would authorise every endpoint". OK if you can implement an authorization requirement simply on a REST endpoint, why could you not implement this simply on a Query-Type field in an equivalent GraphQL API? If this is about authorization on nested data structures: Can you not have equally nested data structures on REST endpoints, too? I think in these cases authorization on REST endpoints wouldn't be sufficient, too. Assuming you would avoid nested data structures: Would this not simply push the n+1 problem from the server side to the client side? My general feeling about the REST vs GraphQL debate is both worlds can in principal cause pretty much the same issues. Even for client side caching I see no real design issue which prevents GraphQL queries and responses to be cached, but probably more like a middleware issue. On the other hand I still see a lot of benefit in using GraphQL: Especially the query flexibility for developers, the solved the n+1 query problem (which may still exists on the rest client side or is solved by a custom solution) and the error handling. I still hate to define exact use of HTTP status codes and custom error payload structure in every context where REST is a new or badly defined concept again and again.
• 6510 2y ago
  I post sql queries to my backend then match them against the exact string. The lack of flexibility is on purpose.
• nprateem 2y ago
  I'm surprised it took 6 years to discover these issues. The N+1 problem and auth/field privacy are obvious on practically any project. In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.
  • dventimi 2y ago
    The N+1 problem doesn't exist on any project that uses, say, Hasura.
  • jhatemyjob 2y ago
    Are you really surprised though? Like you alluded, people use Kubernetes and Bazel just because it has the big ol' G stamp on it. GraphQL is no different (Well... slightly different. It's the FB stamp, not the G stamp)
    • nprateem 2y ago
      I'm surprised it took so long. I worked with k8s and realised pretty quickly it was pointless for my org.
      • jhatemyjob 2y ago
        Yeah that's what I'm saying, it shouldn't be surprising, these delusions last entire careers. Look at all the people who base their career on Java
        • nprateem 2y ago
          I just picked java up again recently and it's really OK now. I'd have used it for my project but spring boot doesn't have an auto-generated admin like django so I binned it.
          • jhatemyjob 2y ago
            The Java thing was a joke lol.
• surfingdino 2y ago
  I worked on two projects using GraphQL and don't want to do it again. Both times the backend was a mess and the "design" or the lack thereof had all the signs of being written by "evangelists" who got bored or got fired leaving the new arrivals to sort out the mess. I'm sure GraphQL is the right fit for some problem domains, but most of the problems I deal with are happily solved with the help of a REST API.
  • electrondood 2y ago
    > written by "evangelists" who got bored or got fired leaving the new arrivals to sort out the mess. BINGO. Someone (VP Eng who was a FE dev) 7 years ago decided shiny new thing was the best and we had to use it, it was owned by FE team, then no one wanted to own it, now BE team has to deal with it, and every dev goes out of their way to avoid it in arch design for new features. Have seen this at two companies so far.
• azangru 2y ago
  Several years ago, I used to respond to conversations where people hated on Facebook by saying that Facebook had given us at least two great gifts — react and graphql. Since then, I've grown to realize that these might in fact be its two great curses.
  • chrisandchris 2y ago
    What do you dislike about React?
    • azangru 2y ago
      Performance. Alex Russell, formerly of Google and now the product owner of Microsoft Edge loves to rant about it. His latest rant is how Edge has significantly improved the performance of some of its UI features by moving off React [0]. [0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faster-microsoft-edge/ https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste...
      • diggan 2y ago
        > [0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faster-microsoft-edge/ https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste... Maybe I'm missing something obvious, but React isn't mentioned in that post. Maybe you put the wrong URL?
        • azangru 2y ago
          Odd, I thought I saw something about React in Microsoft's communications as well. Anyway, here is the horse's mouth: https://toot.cafe/@slightlyoff/112521248529973776 https://toot.cafe/@slightlyoff/112521248529973776
          • chrisandchris 2y ago
            As I read this thread, it's not like "React was the issue, let's move to [other framework]", it's more like moving closer to the plattform brought a performance boost. And that's something I would totally agree. Moving from WebUI to native UIs would even be more performant, and if one would care that much about performance (as said in the thread), one would probably not look at WebUI/Electron/Browser at all and prefer native apps.
• shudza 2y ago
  If only developers/managers had their own sense of using the proper tools for the job instead of just swallowing everything the Big Tech shoves down their throat... But when you see those job ads with all these "great new technologies" it's hard not to fall into the trap.
• icar 2y ago
  At work we also stopped using Graphql and we only have a few endpoints left to migrate in our internal dashboard. Nobody that has worked on this project has liked the dx.
• abound 2y ago
  Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me. One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already 'vetted'", where you can look at things like complexity, ACL behavior, etc ahead of time. Since clients (in my experience) aren't usually modifying GQL queries at runtime, this is a pretty good tradeoff. All that said, I find Buf Connect to be the best set of tradeoffs for most projects: strongly typed servers and clients, strong ecosystem support around protobuf (e.g. to generate an OpenAPI spec), a standard HTTP/JSON interface for easy curl et al compatibility, etc. OpenAPI as the source of truth is annoying because it's too flexible, and it's rarely possible to generate type-safe servers + clients from an OpenAPI spec without running into one edge case or another.
  • tangkikodo 2y ago
    different tool for different aspect. using OPENAPI, rpc, GQL types in client, etc to share typing (schema) information between client/server resolver/dataloader in GQL, eager join in ORM is to handler internal data composition presenter layer should not care about data composition, so that writing Query at presenter is an anti-pattern. presenter should fetch schema info & data passively, like what https://github.com/hey-api/openapi-ts https://github.com/hey-api/openapi-ts did, the job of implementation belongs to backend. In fact what rest/rpc really need is the resolver and dataloader, to help backend easily extend or composing data together, and immediately transferring the schema & data to clients. pydantic-resolve is the python binding for this idea.
  • ko_pivot 2y ago
    +1 for Buf Connect. Great CLI, simple codegen configuration, basically no added runtime complexity — it’s just the serialization layer at that point. It’s also great to be able to use it for both the API layer using JSON while also allowing full gRPC inter-op between backend services, with the same library and workflow.
  • derekperkins 2y ago
• unsupp0rted 2y ago
  Skill issue in my case, but I kept fighting against the caching of whatever GraphQL library I was using. Made the dev experience a nightmare because I could never be sure whether it was my code or the client cache or the (actively in beta) server that was causing me to get back wrong data.
• dventimi 2y ago
  I generally agree and am likewise "over" GraphQL. Having said that, I disagree on some of the finer points. First, some of these issues--authorization, security, N+1--can be mitigated by using something like Prisma, PostGraphile, or Hasura, instead of crafting GraphQL backends with code. Second, there are gains to be made by compiling a GraphQL operation to a single operation in the underlying database's query language (e.g. SQL)--when that's possible--rather than by following the "resolver and data-loader" catechism. Third, as I've written elsewhere recently, I think the N+1 problem is overblown. Not that it doesn't exist, but just that it only sometimes exists and usually isn't as bad as is often claimed. But again, this is eliminated by switching to a compiler approach anyway, so it's not worth making a federal case over it. Despite all this, like I said I'm still over GraphQL. If you must implement it, try to use one of the tools mentioned above if you can.
  • aeonik 2y ago
    N+1 problems were the primary bottleneck in a Websphere backendi worked on for years. Transactions were being aggregated with thousands to 10s of thousands of SQL statements like this. SELECT * from customer where id = <single id> The developers had no idea the ORM was doing this under the hood. It's trivially easy to say that if every SQL statement took 1ms to execute, that thousands of round trips can really start to tank whatever process it might be blocking.
    • dventimi 2y ago
      > It's trivially easy to say that if every SQL statement took 1ms to execute Good thing I don't say that! What I do say is that the number of SQL calls will tend to scale with the volume of data retrieved. Limit the volume of data the user even is allowed to request and you'll naturally limit the extent of the N+1 problem.
  • gmassman 2y ago
    I don’t want to overly generalize, but N+1 problems are very real and frequently occur in code written by more junior developers. Their impact and occurrence rate are dependent on the nature of the application though. I also think there’s an avoidance to simply “translate” a GQL query into an SQL query. Not that it can’t be done, but it allows a lot less flexibility in the backend as far as code patterns that can be adopted. Basically it minimizes the use of ORM models, which may be a pro for some and a con for others. I haven’t worked with GraphQL in over 4 years since I left my last job. I actively made a choice not to use it at my current job and steered the ship towards REST endpoints, mostly because it would be easier to build authorization middleware. Also like the author of the article discovered, code littered with dataloaders is a pain to maintain.
• vitiral 2y ago
  I've read the article and a few of the responses but have never used GraphQL. However I have a question Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc? So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.
  • diggan 2y ago
    > Would it be fair to say that GraphQL is extremely useful for internal-only clients? Compared to what? If you're feeling really safe about the "internal-only" parts, just expose an endpoint to allow SQL (read) queries and you'll get essentially the same thing, especially if your data store already is SQL-like.
    • vitiral 2y ago
      And GraphQL has no real benefits over SQL? If so... I'm not sold
  • crabbone 2y ago
    Just use SQL? A much better language with saner semantics overall. My first and last impression from GraphQL were that whoever wrote it hadn't had a chance to work with other query languages. A lot of the problems OP mentioned were quite on the surface. Had you ever used ORM, you'd be very intimately familiar with N+1 problem. Had you ever encountered SELinux, you'd be painstakingly familiar with authorization problems. Had you ever worked with XML (especially schemas), you'd be aware of parsing problems created by exploiting recursive properties of the grammar. To me, GraphQL feels like a project by someone who is very enthusiastic, but lacks experience. If you need more examples of the same: the Terraform configuration language (not sure what it's called), Neo4j query language (I think it's called Cypher), libconfuse, Protobuf, and many, many more... unfortunately.
    • vitiral 2y ago
      > Protobuf Google's entire software backbone is literally built on this haha. There are things about it I don't like, but it DEFINITELY scales
• dcre 2y ago
  “the main thing your frontend devs like about GraphQL is its self documenting type safe nature” I’ve been saying this for years: fetching multiple things in one query is not something normal-scale apps care about. What devs like about it is client generation and type safety. So OpenAPI, for all its flaws, covers that. GraphQL’s schema language is much more beautiful — hopefully Microsoft’s TypeSpec will take off and we can have the best of both worlds. https://typespec.io/ https://typespec.io/ Another point implicit in the piece but not quite stated is that GraphQL aims to make something nice for the API consumer, but the implementation side is a nightmare. It is not worth the tradeoff because eventually, that nightmare leaks out to the consumer because it is too hard to make improvements to the API.
• dartos 2y ago
  Has anyone use graphql for service to service communication? Seems really great to not have each service adhere to another service’s potentially unstable api contract. Especially if that service is owned by another team.
• ksec 2y ago
  >GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. 6 years. For a lot of people, that was also the time ( 2013 - 2019 ) they moved from SPA or Client Side Rendering and started looking or move back to HTML+ approach. So may be for any company operating on Boring Technology principle, you should not choose any hyped tech until they have been battle tested by the market for 7 years.
• hansonkd 2y ago
  I never understood peoples positions that GraphQL all of the sudden the frontend can make any Query it wants and control is out of the hands of the backend. That seems orthogonal to my experiences with GraphQL. GraphQL is a protocol and you define the implementation. Some GraphQL implementations like REST implementations try to generate everything for you. That is not "GraphQL" but one type. GraphQL is way to query nested APIS. The dataloading N+1 Problems are substantially easier to solve in GraphQL and many frameworks have solutions auto-optimize ORM queries for example. The backend defines the query, the frontend requests it. Simple. Never understood the hate against GQL that now the frontend has all this power. They have exactly as much power as you would have exposed in a Rest Interface just now the backend can actually see all the data it needs at once and optimize. If you are worried about a cartesian product from a GraphQL call I have news for you about production REST systems. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think. REST encourages resource waste. You are getting fields you don't need. Hard to query related objects, etc. Benefits I have reaped with GraphQL: 1. API analysis - I can statically analyze a typescript program and verify their API calls are valid against backend schema. 2. Usage analysis - Statically analyzing the schema I can see which fields are still in use and safely refactor. 3. Frontend Velocity - The frontend can cange its data needs on the frontend query whatever related objects it needs efficiently without backend changes. You can get all data for a page with 1 call and not have to have page specific endpoints. 4. Less backend engineers are needed as API changes less. 5. N+1 Optimization much easier to solve in GraphQL then REST There are so many advantages to using GraphQL. The only advantage of REST I can think of is for static external APIs.
  • tangkikodo 2y ago
    I would like to recommend pydantic-resolve, it can enjoy benefits from botn rest/rpc and gql. the triky part of gql is we need to build a Query system for all business requirement in single entry, and we can not predict what query will be issued by client. this is anti-pattern because presenter layer should not care about how data is composed. It would be much easy if we treat each rest/rpc endpoint as a GQL entry, use resolver and dataloader to quickly & easily build complicated view data, everything is still under the control of backend. here is a demo. https://github.com/allmonday/pydantic-resolve/blob/master/examples/0_demo.py https://github.com/allmonday/pydantic-resolve/blob/master/ex...
• theK 2y ago
  Fine article describing the weak points of GrahQL. I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had we gone with more powerful standards like API blueprint (or maybe raml). Case in point, I'm consulting an org with roughly 1k engineers right now on improving their API ecosystem and what we are seeing is that the more OpenAPI tooling they use, the worse the DX gets...
  • tommica 2y ago
    > I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. What are your recommendations? gRpc?
    • theK 2y ago
      My rant, as evident after that sentence, is about the industry selecting to standardize on Swagger instead of emerging a more powerful/succinct/etc system.
    • bbkane 2y ago
      Someone above recommended https://connectrpc.com/ https://connectrpc.com/ , which looks quite promising to me. Maybe I'll get time to play with it today
  • foobarian 2y ago
    > But the documentation format we chose as an industry to build these things with, Swagger This right here is IMO the biggest advantage of a GraphQL system. What equivalent to GraphiQL is there for OpenAPI? With GraphQL my frontend devs can go shopping for data in one UI, with rich descriptions and strong typing and even try out the queries live.
    • ComputerGuru 2y ago
      You are summarizing the very reason for its existence and popularity: everything is about making the frontend dev’s job easier, at any cost. This is a common theme across the entire web-adjacent industry and has been responsible for plenty of misguided changes and choices.
• greens231 2y ago
  shameless plug: i have been working on https://querydeck.io/ https://querydeck.io/ as a side project to bring the ease of use of graphql to REST apis. the plan is to open source it later in the year once its out of beta
• casperb 2y ago
  I like restful API’s the most. Graphql is cool if you need data combined that is not nicely available in the restful endpoints. But I think that could mostly be solved with good endpoints that help with the actual use cases. When restful endpoints are hard to use, in a lot of cases it is because they are to much focused on how it is easy to write server side, then it is to consume them.
• vendiddy 2y ago
  For something like OpenAPI+JSON REST API, does anyone have recommendations on tooling that would make my life easier? I am also over GraphQL but I really like the api explorers, code completion, type safety, etc.
• knlam 2y ago
  Working with GraphQL over 6 years, I have seen (and created) many mistakes mentioned in the article. GraphQL is not great but it has worked well for me, you just need to adapt & change mindset to create better interface for your graphQL endpoint. For example, having nested queries more than 2 levels is a no go for me (just like having nested inheritance is basically anti pattern) Focus more on your interface. One way to avoid N+1 and nested query is to required parameter for related fields. For example ``` user(id: $userId) { { id friends { id ... } ``` to ``` user(id: $userId) { id friends(id: $userId) { id ... } ```
  • pavel_lishin 2y ago
    I don't think I understand how that change avoids the N+1 issue. It's still fetching all of that user's friends, no?
  • vvpan 2y ago
    I have had to implement a large REST API recently and feel like I spent a lot of time setting up things manually that GraphQL provides out of box. REST tooling has gotten better but so far I have not seen anything as convenient as Apollo, for example.
• presentation 2y ago
  I’ve found success just using GraphQL internally (with tools like Hasura or Postgraphile + row level security done strategically) and not exposing it directly externally. That way you can trust the clients and it unblocks frontend devs to accomplish what they need.
• eatsyourtacos 2y ago
  I only have one experience with a client using GraphQL and it was horrendous. My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that I didn't know about and then I had to constantly ask them for the fields because I thought I was missing data. If I could have just queried ALL the fields, then saw what came in, and chop them down to what I need.. great. The only way GraphQL seems to make any sense is if everything is basically completely defined and you are at a final project stage. After many many years of experience... this is rarely the case. Cool piece of technology? Sure.. but hardly practical except in scenarios of extreme amounts of data and only when it makes sense for the client to return specific fields. Although I think still for 95% of even those extreme cases, you just write a REST endpoint that returns the fields that make sense for the query....
  • tossandthrow 2y ago
    You should have looked at the schema. It indeed seems like GraphQL saved your client in this case.
    • eatsyourtacos 2y ago
      >It indeed seems like GraphQL saved your client in this case. Yeah.. no.
  • steve_adams_86 2y ago
    I think you’re right about it being suited to well-defined scenarios. But I agree too that a regular endpoint to get specific data is more often than not totally acceptable. I’m not aware of many situations where the flexibility of graphql is as useful or important as the demands it places on a team. I worked on a team where 3 of us were well into our second decade of software development, yet we still had a consultant come in to help us sanity check our graphql implementations and ongoing strategy. We were mostly on the right track. The struggles we were having were just… Normal. At that point I really lost steam. Prior to that I was motivated by the thought that something wasn’t clicking yet. Discovering that I understood graphql just fine but it was typically a bad developer experience with obtuse tooling and queries took the wind out of the sails. The worst part was mutations. Writing graphql handlers in Rust was also awful. The more you try to leverage the flexibility of graphql, the more Rust freaks out because you’re doing exactly what you shouldn’t in such a strict environment. Yet… Doing this in a language with weaker typing and less strictness seems like a potential minefield of bugs. I see the appeal of graphql and I’ve liked it in small one-off situations where it was useful but had limited scope. Otherwise I genuinely hope I don’t work with it again.
• redbar0n 2y ago
  There’s a good response to this article here: https://news.ycombinator.com/item?id=40536581 https://news.ycombinator.com/item?id=40536581
• Calamitous 2y ago
  Fundamentally, GraphQL is a _query language_, but people keep trying to build/use it as an _API_.
  • remus 2y ago
    The same thought struck me when reading the article. Imagine a world where your API was 'send me some SQL, return results' and you'd have the same problems as described.
• petesergeant 2y ago
  What are people using these days for TypeScript on both ends? I have a home-grown solution that starts with Zod schemas and gives synchronized types on the front end and backend as well as a client for free, but I'm always interested in using something standard
• mannyv 2y ago
  From a backend point of view, you will never be able to stop front end people from doing the wrong thing with an API. GraphQL makes it easier for front-end developers to do the wrong thing, which is why they love it.
• deadbabe 2y ago
  The consensus I get from these comments is GraphQL is ultimately a failure as a REST API alternative. It’s useful for very specific cases that most companies don’t have.
• adeptima 2y ago
  Back in 2021, I asked one of our devs who badly wanted GraphQL for his resume (this dev left in 6 months) to address the following issues: - GraphQL performance issues - GraphQL makes tasks more complex - GraphQL schemas confuse junior devs, higher entry level - REST cache easier - REST if you understand what you are doing ... can do the same - REST is better for error handling and tooling Now in 2024, I clearly see LLMs gives much better autocomplete for REST or SDK code generated with protobuf ecosystem There is not enough code repos based on GraphQL for LLMs to reason. If you have like minded people who loves GraphQL, nothing can stop them but at higher and broader level it's a huge risk for dev velocity (like anything else if you dont know what you are doing)
  • merrywhether 2y ago
    Given that GraphQL makes much more sense for big orgs, I wouldn’t be surprised if much of that code is locked up in private repos that LLMs can’t get to.
• chuckadams 2y ago
  I must be the only one who found GraphQL, used it in a small project, and liked almost every bit of it. I used Apollo Client and graphql-codegen to generate types and functions for Vue 3, and nothing else could touch it. It wasn't all smooth sailing of course: I did find defining new scalar types to be fiddly, and I couldn't really even make proper use of union types, directives, or even enums due to the impedance mismatch of Apollo Client (JS) and API Platform (PHP). The latter had a lot of nice features in implementing the API backend itself, but the poor documentation for its graphql support held me back. But even the super-basic graphql subset I did use caught a great many errors at the type level where other solutions would not have. These days, given the freedom to write the backend in TS too, I might look into tRPC instead. One thing's for sure, I won't be going back to OpenAPI unless and until I can fully autogenerate api.yaml and otherwise never have to touch it again (getting there with zod+openapi on another project, but it's nowhere near as easy as graphql-codegen doing all the things with one introspection query).
  • moribvndvs 2y ago
    After building several GraphQL-based applications, the design time experience and expressivity offered to UI developers particularly when the application is first starting out feels really great. But like the author, it sours quickly after that. I found myself spending a large amount of time inventing and trying to patch in solutions that most RPC and REST frameworks solved long ago for both the server AND the client (auth, rate limiting, error handling and validation stick out particularly). Client solutions are comparatively heavy, complicated, and riddled with gotchas (e.g. caching) that trip up new team members more than REST. It’s not impossible to build performant GraphQL solutions, but the solutions feel more like afterthoughts and require more vigilance to ensure your team doesn’t stick their finger in an electrical socket compared to REST. The lack of namespacing or organization results in almost unintelligible query and mutation documentation for large projects. The comparatively large size and complexity of requests can be a headache for ops teams. I loathe that interfaces and inheritance don’t work for mutations. Front end devs just use it like a very heavy REST and the holy grail promised by stuff like Relay never materializes. I could go on. And at the end of the day, the app’s API usage will stabilize and mature, and the expressiveness becomes less compelling compared to its cost. When I went back to OpenAPI and REST, it was like a breath of fresh air, I felt I was building things much faster. I will grant you that generating clients from OpenAPI still is the worst part.
• stratigos 2y ago
  The hype train strikes yet again! In fellow consultancy circles, we were giving talks on exactly this back in '17 and '18, but the hype train was too strong then. It was even harder to convince this same crowd that SPAs are usually a bad idea, and emerging technology like Hotwire or LiveView would soon eclipse the SPA-obsessed culture. GraphQL is immensely powerful and useful for its exact use case, and extremely burdensome and expensive for any other use case. If you dont already know that use case, YAGNI. The same can be said for any hype train. The problem with any kind of hype train in tech is everyone looks for reasons to use whatever the new hyped thing is, rarely does anyone determine if the new hyped thing actually fits their use case(s). This will continue so long as there is a dichotomy of culture between youths and those with lengthy experience. We old people will continue to point out exactly why this or that is pure hype, and will continue to be drowned out by the emotions that come along with participating in hype.
• electrondood 2y ago
  GraphQL is a great way for FE devs to make life harder for BE devs. The entire point is composition + client customization of the response body, but in practice the request schema is never modified. And even if it were, you could just version a REST endpoint. GraphQL is never done "correctly," adds a layer of obscurity to monitoring and error tracing, and I've yet to see a case where it's actually the right tool for the job. Maybe if you need to aggregate calls to multiple services into one, but if you're trying to avoid latency by reducing number of calls, you still eat that latency while the GraphQL server makes those calls for you. GraphQL sucks.
• Ozzie_osman 2y ago
  As an alternative datapoint, we use GraphQL for a medium-sized app, are several years in, and are pretty happy with it. The downsides he mentions are all true, but on the other hand, are addressable, and for us feel worth the benefits of getting flexibility and control on the client-side.
• awirick 2y ago
  I've run into all of these issues running a GraphQL API and, while they aren't easy, they aren't exactly intractable either. Let's not pretend that OpenAPI/REST or Protobuf are perfect alternatives. They've each got their warts and tradeoffs. The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you may still have to reason about graph-like structures but without the benefit of a graph-like schema.
  • hot_gril 2y ago
    OpenAPI can do graphs too, since you can put in refs to objects that can themselves have refs to other objects, possibly recursively.
    • RedShift1 2y ago
      At that point you've recreated the exact same problems many here are complaining about, N+1, authorization on leaf nodes, ability for the client to create queries that are hard to optimize, etc...
      • hot_gril 2y ago
        The client doesn't create queries in this situation, you explicitly define them server-side. So optimization is easier. I've seen this time and again with services that aren't GraphQL but tried to provide a semi-freeform query feature; if you only have a few clients and control them all, it's way easier to just make separate endpoints for whatever they need. If you have many clients, maybe GraphQL makes sense. Auth on leaf nodes, maybe I'm not understanding the issue but it seems solved without GraphQL. JWTs are one way.
• deleted 2y ago
  [deleted]
• mcdonje 2y ago
  >1. Write a succinct human readable TypeSpec schema >2. Generate an OpenAPI YAML spec from it Why? Isn't YAML human readable?
  • emlos 2y ago
    Yes, but OpenAPI specs tend to be verbose and hard to navigate. Remembering the exact anchor for the type you defined can be difficult, finding the reference can be harder, and you probably won't get any help from an IDE. I tend to prefer just writing the yaml, but I can also see why these kinds of tools crop up to mitigate the need to remember all the details.
• emorning3 2y ago
  Odata is 80% of GraphQL with only 20% of the hassle.
• finack 2y ago
  Well yeah, who knew that letting your frontend developers blow up your database because nobody talks to each other or designs things anymore would be a bad idea?
• hot_gril 2y ago
  I started at the same conclusion of using OpenAPI and never ventured into GraphQL cause I only had one client.
• mirekrusin 2y ago
  Just use jsonrpc over websockets - you’ll have same semantics as function calling in your programming language, type it if you’re using static type aware lang and have happy life. It’s easy to optimise, refactor, trace/debug, use (same as using library with async functions) etc.
  • mdaniel 2y ago
    > trace/debug, for whom? when was the last successful experience you had of telling a product manager to open their devtools and find the row in a websocket handshake showing the actual payload that went over the wire for the timeframe in question? I am open to the fact that maybe there are super advanced organizations which have replay debuggers or Sentry or whatever that remove the need to utter the dreaded phrase "can you open the devtools?" but I regrettably haven't worked in one
    • mirekrusin 2y ago
      Nobody is looking at websocket handshakes. What I meant relates to simplicity around recording communication - req+res+duration and notifications, the fact that semantics are familiar and very clear, it's easy to filter/plot/explore it, everybody knows what is happening, where to optimize etc.
• mbleigh 2y ago
  TL;DR GraphQL isn't really the problem, untrusted clients executing arbitrarily complex queries is the problem. This is why authz is hard, why rate-limiting is necessary, why "query complexity" calculations are necessary... At Firebase we chose GraphQL as the basis for our new Data Connect PostgreSQL product (https://firebase.google.com/products-data-connect https://firebase.google.com/products-data-connect) despite acknowledging pretty much all of the issues outlined in this article as correct. GraphQL is an excellent IDL (interface definition language). It's compact, it's flexible (through directives), and there's literally no better way I'm aware of to rapidly construct complex nested relational queries. But the promise of "clients can fetch whatever they want" adds an enormous burden to backend developers because you have to secure yourself against queries of arbitrary shape and complexity. In reality you don't want clients to "fetch whatever they want" because clients can't be trusted. The path we took is that developers can predefine the queries that are needed for their client, and then only those queries can be executed from an untrusted client. This approach provides a surprising number of benefits - you get the flexibility of nested queries and field selection, the end-to-end strongly typed structure of a schema-driven API, and the ability to reason about security like it's a custom backend.
• victor106 2y ago
  This is a great post!!! Not just for the content but I love it when someone changes their mind (very very hard thing to do) and details out what led them to change.
• rglover 2y ago
  Worked with GraphQL from 2017 to 2021. It was the last tech "hype" I bought into. At first, it made a lot of sense and the thing that got me was the structure. But eventually, I realized how much extra work and duplication of everything there was. At the time, too, things that should have been easy like subscriptions had a nightmare API packed with weird terminology that made implementing simple features a slog. The one positive to come out of working with it (aside from knowing how to spot a tech black hole) is that it informed the design of the API layer in my framework [1][2]. I realized the sweet spot is starting with a basic JSON-RPC type endpoint and then layering things like input validation [3], authorization [4], and selective output [5] (only requesting certain fields back) on as you need them. [1] https://docs.cheatcode.co/joystick/node/app/api/getters https://docs.cheatcode.co/joystick/node/app/api/getters [2] https://docs.cheatcode.co/joystick/node/app/api/setters https://docs.cheatcode.co/joystick/node/app/api/setters [3] https://docs.cheatcode.co/joystick/node/app/api/validating-input https://docs.cheatcode.co/joystick/node/app/api/validating-i... [4] https://docs.cheatcode.co/joystick/node/app/api/authorization https://docs.cheatcode.co/joystick/node/app/api/authorizatio... [5] https://docs.cheatcode.co/joystick/ui/api/get https://docs.cheatcode.co/joystick/ui/api/get (see output array in the function options API)
  • hot_gril 2y ago
    I'd much rather find out the hard way that I need something than find out the hard way that I don't. There was one project where OpenAPI became a bit painful and I rediscovered why GraphQL could make sense, but it didn't reach the threshold.
    • hot_gril 2y ago
      (To be clear, OpenAPI was the baseline I was already comfortable using, and GraphQL was the heavier approach I wasn't sure about.)
• powersurge360 2y ago
  I think GraphQL works its best magic when you are building your own unified data access layer for a backend. Your individual services can be backed by Postgres or Mongo or an in memory database, whatever, doesn’t matter. And from there a backend queries that, translates the data into a RESTful one, and passes it along to a front end Backends-for-Frontend style. In this way services get freedom to define their stack while still neatly fitting into the suite of services, products get a tidy interface from which to query everything, and because the GraphQL consumer is more akin to a regular database consumer, the database muscle memory kicks back in. I’ve also grown to prefer bespoke backends for each client over a super backend that tries to anticipate all of the needs of all the clients. It just opens too many holes and what it buys in versatility for the client author it also gives to the exploit author.
  • gedy 2y ago
    Sounds like you are describing the Backend For Frontend (BFF) pattern and I also quite like it.
• smrtinsert 2y ago
  Graphql via spring is easy integrates seamlessly. Obviously stick to its core use cases and it will go great.
• rambojohnson 2y ago
  yes, let's conflate bad API / schema design with GraphQL / the technology being the problem.
• edude03 2y ago
  Despite all of these things ringing true for me as well at the last few companies/projects I worked at that used graphql, I will say that like everything in tech, there are trade offs, but if the tool generally solves the problem you have well, you'll be motivated to find solutions to the additional problems you have - which often means the argument actually comes down to who is more passionate about the particular tech. One example that stood out to me though: > GraphQL discourages breaking changes and provides no tools to deal with them. GraphQL the standard doesn't provide tools no, but I've been very successful using Apollo Studio to solve this as (in my experience) the workflow maps to how you generally develop applications: 1) agree on some schema 2) make a (Apollo studio) "branch" with the schema change 3) mobile & backend devs (typically) code gen the objects they need for the schema 4) backend dev deploys a preview branch of their implementation, mobile dev points the client to it 5) test it, merge it, publish the schema on the main "branch" - deal with the breaking changes if Apollo warns you of them. So maybe you can accomplish this with other tools, and maybe it's not fair to compare "the standard" to a particular tool, but I usually say I stick to gql (where appropriate) because there is a tool for it that works so well for the problem(s) I'm typically solving.
• phaedryx 2y ago
  I worked on a GraphQL API a few years ago and we solved these problems at the beginning and then forgot about them. We generated the schema for a user from their CanCan abilities (CanCan can handle attribute-level access, I wrote the PR). Shopify has support gems for the N+1 stuff, if I remember correctly. You can limit how many levels deep your query can go. We added some rate limiting. Basically, these are all solved problems.
• SJC_Hacker 2y ago
  I never understood the problem that GraphQL was trying to solve. If REST doesn't work for you, I don't see what was wrong with query strings, or JSON parameters.
• joshstrange 2y ago
  I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want nothing to do with GraphQL anymore. Everything we attempted to fix our permissions issues just caused more problems. It would break existing queries and debugging GraphQL sucked so much. If you only live on the frontend and someone else is responsible for the backend GraphQL then I understand why you might like it. From that perspective it's amazing, you can get as little or as much as you want with the specific fields you want. No waiting on the backend team to write an endpoint. However even then you end up saving queries as files or abstracting them (maybe IDE support has improved but it wasn't great last time I was using it ~5 years ago) and now you just have REST endpoints by another name. At one point we considered whitelisting specific queries and that's when I knew we had gone too far and made a mess for ourselves. If we had taken the time to just write REST endpoints instead we would have gotten way more done and had way fewer grey hairs.
  • hosh 2y ago
    Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production. Though I guess you can do that with REST too. I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backend. I was not sure why this pattern is not more popular, but reading all of this now, I'm seeing where these problems may arise. A graph db backend can use efficient graph search algorithms, especially for deeply nested data, but the issue with authorization is still there. If anything, fine-grained authorization is something better represented with graph dbs than with relational databases.
    • groone 2y ago
      Entity Framework Core has got you covered! Writing some LINQ and returning data in Aspnet Core API takes no time at all.
• bilater 2y ago
  I never understand how people end up needing overly complex queries (REST or GRAPHQL). Maybe it's harder to coordinate in bigger orgs but I have almost always found its better to go to the DB, create some logic there like a new table or sql view and do a simple query from the client. It keeps thing way more performant and simple.
• unnouinceput 2y ago
  I worked with CORBA during 90's and early 2000's. A truly shitty piece of technology that I do not wish upon my worst enemies, except maybe the higher ups at Microsoft who invented COM interfaces. When I saw the hype of GraphQL in 2017 I looked into it and while exploring it I started to have PTSD from CORBA days. "So you're the new CORBA, huh? I'll fuck off as far away as I can from you then" - and told the same to every client that even mention it.
• victor9000 2y ago
  My experience is that a stable graphql server is dependent on well behaved clients, which is not something you control.
• nojvek 2y ago
  REST is simple and works well with debuggers, logging, caching, auth, request throttling e.t.c For graphql like needs we use a standard set of props (select, filter, sortBy, limit, offset). They map to a single sql statement and executed efficiently by PG. select can be nested properties if we need deeper nesting. Server emits typescript types package for frontend. It's worked really well so far at our scale. Eng team is fairly productive.
• frabjoused 2y ago
  For some reason every person I have worked with that pushed GraphQL seemed sufficiently obsessed with the idea of it that they prioritized its perceived elegance over the product we were trying to build. In other words, they cared more about ideal ways to access data than the product of that data. This has so consistently been the case in my personal experiences that I avoid people in hiring interviews that start talking about or try to sell me on why I should switch my stack to GraphQL.
  • eYrKEC2 2y ago
    Advocating for graphql as a red flag. I like it.
• jupp0r 2y ago
  95% of this is specific to Ruby, not GraphQL. I also found ruby-graphql not to be a excellent library in contrast to what the author says. Other implementations (apollo for node, gqlgen for Go) alleviate many of the concerns mentioned in the article, especially when implementing the server with certain principles in mind (always use the data loader pattern, etc).
• iamyemeth 2y ago
  Why, after 6 years, I'm over increased complexity for marginal benefit. Sounds like most things developed and promoted by FANG
• patricius 2y ago
  I will, once again, bring your attention to hashql, which is so pleasant to use. It's so minimal that it is almost more a pattern than a library. Try it out as an alternative to graphql if you are mainly querying a SQL database anyhow (although it can be easily configured to request data from other types of sources.) I don't think it can currently combine results from multiple data sources, but I think it should be within the realm of possible things https://github.com/porsager/HashQL https://github.com/porsager/HashQL
• ttfkam 2y ago
  The only time I think GraphQL works is when it is when the GraphQL schema and resolvers are autogenerated by the underlying data stores. As a ORM layer, I love solutions like Postgraphile and Hasura where they mostly just reflect the structures you've already designed in your database. I also like REST solutions like PostgREST for the same reasons. Then I'm designing my table structure, optionally designing my views when I don't want a 1:1 reflection of how data is stored, setting up row-level security at the data layer, and making user-defined functions for the one-offs that deviate from plain CRUD. But solutions like Spring DGS for Java, Graphene for Python, and Apollo for Node? No thanks. Never again. Way too much trouble and pain. I'd rather make lambdas that talk to the data store directly and output HTML than make and maintain a GraphQL schema manually again. I really wish Postgraphile and Hasura were more popular, so folks could have skipped the low level plumbing and optimization fences like dataloaders that make GraphQL such a chore otherwise. It really is elegant when you're not stuck in a swamp.
  • damidekronik 2y ago
    Postgraphile is great, until you need to debug row level security. Or when you realize you need another tool to make the query type safe.
    • RedShift1 2y ago
      What troubles have you had with debugging row level security? It has worked very well for me, I've not had issues debugging it. And what do you mean with making a query type safe? Type safety is built in to GraphQL, if you send in the wrong datatype for an input the query will be rejected without even hitting the database.
      • ttfkam 2y ago
        Unit testing row-level security policies is far from the hardest thing to test/debug. Not sure what this guy is talking about.
• valenterry 2y ago
  For professional developers that know more or less what they are doing, most of those things are absolute non-issues. Let's list it: > if you expose a fully self documenting query API to all clients, you better be damn sure that every field is authorised against the current user appropriately to the context in which that field is being fetched. The same is true for a "regular http API" [now abbreviated as "rest API"] (in case it's not clear: imagine how the http API would look like and think about if it would be somehow magically secure by default. Spoiler: it won't). Security by obscurity was never a great thing. It can help, but it's never sufficient on its own. > Compare this to the REST world where generally speaking you would authorise every endpoint, a far smaller task. Just think about how many endpoints you would actually need to cover all combinations that the graphql API offers. > Rate limiting: With GraphQL we cannot assume that all requests are equally hard on the server. (...) It's true. However: a rest API only makes that easier because it's less flexible and you have to manually create one endpoint for each of the various graphql API combinations. So instead, a classical graphql mitigation that the author does not mention is to simply require the client (or some clients) to only use fixed (predefined) queries. That is then the same as what a rest API does, problem solved. So graphql is not worse of here, but it can be much better. > Query parsing This point is actually fair, except for the claim that there is no equivalent in REST. That is simply not true, as there have been many cases where rest frameworks worked with json and could be ddos'd by using large json numbers. > Performance: When it comes to performance in GraphQL people often talk about it’s incompatibility with HTTP caching. For me personally, this has not been an issue. Funny, because that is indeed one factual disadvantage of graphql. > Data fetching and the N+1 problem: TLDR: if a field resolver hits an external data source such as a DB or HTTP API, and it is nested in a list containing N items, it will do those calls N times. No, this is wrong. But first: this problem exists in a rest API as well, but worse: instead of N+1 queries to the DB, it will N+1 http requests AND N+1 db requests. But with graphql and some libraries (or some handwritten code) it is comparibly easy to write resolvers that are smart and "gather" all requests on the same query level and then execute them in one go. This is harder to do in a http api because you definitely have to do this by hand (as the auther describes). > GraphQL discourages breaking changes and provides no tools to deal with them. What? Comon. In a rest API there is no means to do anything against breaking changes by default. Graphql at least comes with builtin deprecation (but not versioning though). > Reliance on HTTP response codes turns up everywhere in tooling, so dealing with the fact that 200 can mean everything from everything is Ok through to everything is down can be quite annoying. True, but that can be adjusted. I did that and made it so that if all queries failed due to a user-error, the request will return 400, otherwise 204 if they partly failed. > Fetching all your data in one query in the HTTP 2+ age is often not beneficial to response time, in fact it will worsen it if your server is not parallelised Okay, I'm starting to be snarky now: maybe choose a better language or server then, don't blame it on graphql. And actually, many real problems of graphql don't even get mentioned. For example: graphql has no builtin map type, which is very annoying. Or, it has union types in the response, but you can't use the same types as inputs due to a lack of tagging-concept. And so on. My conclusion: the auther is actually fairly inexperienced when it comes to graphql and they probably had a bad experience partly due to using ruby. My own judgement: graphql is great except for very very specific cases, especially in projects that require huge amounts of servers and have a high level of stability in the API. I would always default to graphql unless the requirements speak against it.
• rbalicki 2y ago
  Folks on this thread should check out Isograph: https://isograph.dev https://isograph.dev and https://www.youtube.com/watch?v=gO65JJRqjuc https://www.youtube.com/watch?v=gO65JJRqjuc. GraphQL has a lot of advantages, the most important of which is data masking. In a properly structured GraphQL app, only the function that requested a field (i.e. included it in a fragment) sees that field. This allows many developers to move independently, without communication or coordination. It's unfortunate, but there are lots of rough edges with GraphQL and it is hard to incrementally adopt, and so if you don't have enough developers (to have communication issues) and a team devoted to adoption, it might not be worth it. Anyway, Isograph is a framework that seeks to take away many of those rough edges, while baking in stuff like data masking, etc. Y'all should check it out!
• garydevenay 2y ago
  I admire the 6 year dedication (or architectural investment?). We were both jumping aboard that hype train in 2018, even talked about it in meat-space. I left that project in 2019 and never looked at GraphQL again, so didn’t make it as far you to the technical depths. Something just never felt right about the client building the queries for me, I guess.
• nailer 2y ago
  Your most precious resource is time. I'm really glad of the time I invested in Python, node, TypeScript, Virtualisation and Serverless. I'm less happy about the time I wasted on bash, DOOM WADs, and Desktop Linux. Yes these are are all a while ago. I didn't invest my time wisely when I was young. I'm also glad I didn't invest in GraphQL, Kubernetes, Angular, Solaris, and perl.
• rootedbox 2y ago
  GraphQL.. when people didn't learn their lessons from SOAP..
• deleted 2y ago
  [deleted]
• kabes 2y ago
  Except, the alternatives he presents aren't alternatives. And for each issue he mentions that rest doesn't have said issue is basically because rest doesn't have the feature at all. You could use graphql the same way as rest (by exposing queries without allowing to specify fields) and you still have a better rest, since at least the response has a schema out of the box.
• santoshalper 2y ago
  Of all the dumb ideas in the history of engineering, exposing an access point for strangers to query your database is certainly one of them. I cannot imagine that anyone involved had experience running enterprise systems at scale.
• mocamoca 2y ago
  If someone from Shopify's backend team is around, i would love to know how difficult it is to maintain/improve the GraphQL API It looks like Shopify is deprecating REST in favor of GraphQl so is the developer UX that good for Shopify developers? And btw some features are missing from the GraphQL related to REST. I wonder if that's related to hard-to-implement features or good-occasion-to-delete features (Eg Checkout)
• andy_ppp 2y ago
  Using Elixir+Absinthe solves most of these problems and the idea that a non-self documenting API doesn’t need every field to be secure is quite frankly a ridiculous thing to label as a problem for GraphQL, maybe the self documentation encourages better security practices, who knows!?
• qaq 2y ago
  One context it works well in is something like PostGraphile. You basically spend very little time developing the back end. This obviously does not scale to very large projects.
• GenCuriosity 2y ago
  And with spec first and OpenAPI Spec we are back to the methods and tools, that we hadwith WSDL/XSD and SOAP/XML like 20 years ago. We went full circle. :) I love IT The problems with GraphQL where so obivious in the first 5 minutes that I looked into that. Looks smart and flexible - but isn't
• PurpleRamen 2y ago
  > Tab Grouping, Vertical Tabs, and our handy Sidebar will help you stay organized no matter how many tabs you have open — whether it’s 7 or 7,500. Not sure if this will be good. This reads like they will add Vertical Tabs as a Sidebar, like all the other vertical tab-addons doing it now. But since the Quantum-update there is demand for a second sidebar dedicated for tabs, because as it's now, sidebar is really annoying to use. But maybe it will at least add some improvements which the other addons can built upon. > More streamlined menus that reduce visual clutter and prioritize top user actions so you can get to the important things quicker. Oh gosh, no! Why make them even worse than they are already now?
  • lbourdages 2y ago
    I think you replied to the wrong post :)
• rootusrootus 2y ago
  We are in the process of winding down our biggest GraphQL attempt, after years of trying to make it work well. Nobody is feeling sad to watch it go, that is for sure.
• michilehr 2y ago
  I totally agree with every point. GraphQL can be very powerful, but also very dangerous.
• megalord 2y ago
  Many of you guys probably don't even need API for web development. Same as we didn't. We rewrote codebase, removed React and Graphql part and now Django serves html. Win win for everyone. We don't have mobile app and don't even plan, but if we do, we always can implement some rest api.
• rezonant 2y ago
  I have never bought the GraphQL hype, but have never explained my rationale as well as this article does. Kudos Matt on succinctly nailing the issues here. As for how to tackle things today, I alternate between REST+OpenAPI and RPC models for communication. I am certainly biased as I have my own typed open source RPC library (Conduit) which is layered on top of arbitrary message passing transports such as WebSockets, but as of yet it's only suited for Typescript-based clients -- REST+OpenAPI is a better fit for an API with many consumers. But for dynamic client/server and client/client single-implementor communication needs, I go with RPC.
• localfirst 2y ago
  You notice Facebook is increasing complexity across the board? Frontend - React Backend - GraphQL What's extra creepy is the private equity firms squeezing this space dry
• cletus 2y ago
  Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL. Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps: 1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has; 2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data. 3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data. Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other. The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak. How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.
  • lkysow 2y ago
    Is the DB you use open source?
• tango12 2y ago
  I’m the founder of Hasura - sharing some notes from how I’ve seen GraphQL usage evolve over the last few years. 1. GraphQL was and remains insanely hard to build without an underlying data layer that does the heavy lifting. Without projection push-down, predicate push-down, a data layer that can support heavy parallelism it’s untenable. Exactly the problems the OP highlights - needing to “hoist”… 2. GraphQL on REST is an anti-pattern. The hype takes you there, but the juice is not worth the squeeze. The problem was lack of types? Add openapi. The problem was custom aggregation endpoints? Make it super easy / cheap to build aggregate endpoints in REST. Use an AI copilot to write an aggregate REST endpoint and a openapi schema for it even. But maybe the last thing to do is to build annd mainatian another API layer with a completely different execution model. It’s not what it was meant for perhaps, but GraphQL’s killer use-case is an API to access / operate on data. Especially when there are multiple consumers of data (services, apps) and they don’t own the underlying data sources or speak the underlying language of the database. This turns out to be the underlying problem behind a lot of api, data modernization / migration / decomposition efforts. The cost of this approach is implementing Graphql by building a compiler/planner with a robust authz system baked into it. A resolver based approach can never cut it, unless you resolve a query plan - aka build a compiler. If you want to use graphql to just batch rest endpoints, it’s very likely going to become legacy tech as soon as the team that built it starts to move on.
  • jeanlucas 2y ago
    > GraphQL on REST is an anti-pattern. Yes.
  • sebmellen 2y ago
    We built Yates (https://github.com/cerebruminc/yates https://github.com/cerebruminc/yates) to solve the authz problem. Yates implements Postgres RLS along with Prisma, which we use as our ORM, and then our GraphQL schema is generated using TypeGraphQL (https://typegraphql.com/ https://typegraphql.com/). Overall, it's a very nice setup and allows us to be versatile on the client side while still having strong authentication integrity. While perhaps not as polished as Hasura, this stack does have the nice benefit of being free ;-)
• tormeh 2y ago
  I learned REST first, then I started working somewhere with gRPC. It was a revelation. Type-safe APIs! I was sold. Now I work somewhere where we’re all-in on GraphQL. It’s just a massive pain for very little benefit. In many ways it’s worse than REST. It really only works well if you’re writing something meant to behave like a database. Normal backends don’t want to do this.
• shagie 2y ago
  I've come to believe that the "right" way to do things now is alternating smart / dumb layers. If you have two smart layers adjacent to each other (and GraphQL is a smart layer) then the interconnection between the two and the conflicting abstractions of data becomes an issue. By having something dumb (REST endpoints) between the business layer and the complexity of the front end, it is possible to have reasonable abstractions writing to the REST endpoints and an abstraction of the payloads that the endpoints provide into what is needed in the front end application. It seems that GraphQL works best when the backend has minimal business logic and the thing that is calling GraphQL likewise has minimal logic -- and all the logic is contained in the GraphQL query itself. But if you're finding complexity in getting things into GraphQL and manage permissions and mutations... or you've got the complexity of the front end where the data model the front end needs to work with doesn't align with the GraphQL model ... then you've got complex solutions abutting each other and those spots is where the pain will be found.
• devit 2y ago
  I think the only reasonable way to use GraphQL on a freely accessible server is to only allow a set of whitelisted queries, ideally automatically extracted from the frontend codebase, stored on the server and invoked by id and arguments. This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL API rather than knowledge of the whole backend architecture, which is generally useful if the backend and frontend are written by different people or teams. That's the way Facebook uses it on their main website: they pass the query id in the "doc_id" form field, the arguement in the "variables" field, the server gets the actual GraphQL query based on the doc_id from some sort of internal dictionary and AFAIK no GraphQL query string ever goes on the wire in production.
  • gedy 2y ago
    > I think the only reasonable way to use GraphQL is to only allow a set of whitelisted queries That's already how it works, it is not an open ended SQL query. The GraphQL schema is the whitelist.
    • devit 2y ago
      No, I mean of whitelist of full GraphQL queries with string/number arguments, where you can only run one of the queries in the whitelist, and the client can only choose which query and the string/number values, but not submit an arbitrary query string.
      • gedy 2y ago
        The schema you expose can do that afaik.
• elux101 2y ago
  another project to take a look at for schema-driven approach to writing backend services and fully code-generated clients: https://github.com/webrpc/webrpc https://github.com/webrpc/webrpc it's similar to OpenAPI, but its simpler, and cleaner. In fact, you can generate webrpc schema's to OpenAPI and then generate OpenAPI clients.
• socketcluster 2y ago
  This is a great write-up. I was already aware of most of the drawbacks that the author wrote about in the early days of GraphQL... Another category of solutions which was ignored completely is CRUD with field-granularity over WebSockets. I've built platform which does just that: https://saasufy.com/ https://saasufy.com/ This approach has allowed me to create a library of highly generic components which can be composed into surprisingly complex front ends and where all data updates in real time (in a targeted, efficient and scalable way): https://github.com/Saasufy/saasufy-components?tab=readme-ov-file#saasufy-components https://github.com/Saasufy/saasufy-components?tab=readme-ov-... You can build just about any front end you can imagine just by assembling these components. Almost no code needed. It takes me hours to build web applications which would take weeks or months to build. The real time update features come free. The dev experience is essentially bug free; any 'bugs' you may encounter have clear visual symptoms which can be 'debugged' by observing the HTML DOM. I'm currently observing people getting hyped up over HTMX and it's kind of funny to realize that developers do actually like the declarative approach... And yet they're going in the wrong direction again. Just as they did with GraphQL. It would have been impossible to do this with GraphQL because field-granularity/autonomy is essential. GraphQL queries combine different resources and fields together in complex ways and this makes it impossible to efficiently avoid real time update conflicts on the front end.
  • deleted 2y ago
    [deleted]
• cellularmitosis 2y ago
  We tried GraphQL for about a year, then switched back to REST, but took the important bits with us: a published API contract (an OpenAPI spec), and code-gen'ed Swift from that spec. Looking back, it is hard to believe I spent a decade working in shops with no published spec, no code-gen. So many ugly surprises discovered in production, all of which were avoidable. Never again.
• zamalek 2y ago
  > Rate Limiting... OOM... There is no REST equivalent to this attack of this severity. Yes there is, simply throw JSON such as `[[[[[[...` at the server. You probably don't have to get into parsing though, nearly all C# (and Node, and Ruby, some Rust even) assumes that memory is, in-fact, infinitely large and just throw network input into a precisely-sized buffer. Just upload a few GB of nonsense to an API endpoint, bonus points if you omit Content-Length.
  • wtetzner 2y ago
    I dunno, the REST endpoints I've worked on enforced a maximum message length.
• parentheses 2y ago
  GraphQL is an opaque layer that is not necessary in the truest sense. The lie is that it makes things better. 100% of the time that I add an unnecessary thing to a project in the name of "it will make things better", it never did. It's the old new-shiny, so here we are lathering on our dislike, which I feel is totally normal and expected. There's a new new-shiny around somewhere and a few years from now, I'll see articles like this one about it. Having not yet read the comments, I plan to enjoy them thoroughly, I love a good hate-post about software I myself don't like. :)
  • aprilthird2021 2y ago
    I'm curious about this. Do you think GraphQL makes things worse in its intended use case: allowing different clients to control how little or how much data they pull. I have been, like you, baffled by places that insist on using GraphQL for a biz software website that they barely support on mobile, or an app-only product with limited to 0 web support. But for situations where you want both a robust mobile app (sometimes multiple), and a robust web app (sometimes multiple), I don't know if there's a better solution that keeps the frontends and one true backend decoupled as well? Curious what you say or what I may have missed for this scenario.
• tusharmath 2y ago
  My response to the blog above https://blog.tailcall.run/writing-a-graphql-backend-by-hand-is-long-gone https://blog.tailcall.run/writing-a-graphql-backend-by-hand-...
• j45 2y ago
  A lot of good reading and learning in the comments about where graphql usage can end up. Has anyone experienced something similar with typedb? It feels a little too good to be true. Make it seems like graphql and nosql trauma.
• marcus_holmes 2y ago
  Last time I used GraphQL the front-end devs ended up writing a single query to hydrate the entire data model in one pass, so they could be sure the data was present for all the components. We spent a month on the backend enabling GraphQL and we could have saved that and written a single "api/getAllTehData" REST endpoint in about half an hour. I'm looking at Shopify API at the moment, and there's a notification that they're deprecating their REST API and moving it all to GraphQL. I hope it's a joke. But I suspect not. Enshittification intensifies
• robbyiq999 2y ago
  I remember about nearly 6 years ago gql showing up in job postings, I scratched my head a bit because it was so new. And also just a QL, why hire based on it? Shouldn’t you pick techs easy to use AND LEARN. Thereby nullifying must-have-experiences Perhaps now it might be; Nice to haves: Enough experience with GraphQL to never suggest nor implement it. These are the kind of experiences I think which truly matter.
• tangkikodo 2y ago
  We just need a tool to let every REST/rpc endpoint gain the ability of 'resolve' and 'dataloader' from GQL, to provide rich detailed view data to frontend (in just single call) So that: 1. we enjoy the current tech stack from REST/rpc 2. we gain the ability of quick composition from resolver / dataloader 3. with iteration, we can replace/ refactor endpoint without breaking anything. for fastapi user, the lib 'pydantic-resolve' can help.
• masfoobar 2y ago
  In my younger days, I always felt pressured to use ProductX especially when it is praised and/or considered the next big thing. You can refer to javascript frameworks, libraries, even "cool, new" programming language. I remember working on a Rest API and thinking about (things like) GraphQL... the typical "would it make life easier" and all that. In the end, as the years have passed, I just stick to the minimum. If there is a tried-and-tested library or something.. I use it. When there is something new, I question it. Never tried GraphQL. It looks like it can improve my data on one end, but cumbersome when it is hard to reason the data, or get generally complicated, which this article demonstrates.
• deleted 2y ago
  [deleted]
• DonnyV 2y ago
  Now lets do Docker next. :-)
• fl0ki 2y ago
  I have another one for you. GraphQL should never be used as a way to "GET-modify-PUT" records, but often is, because why reinvent GET if you already have GraphQL? Because the query specifies the fields, so if new fields are added to existing types, existing clients don't receive them and PUT the record back without those fields. You now have to try to deal with this in the backend, with subtle and severe edge cases potentially affecting the backend and all of its clients.
• theghostoftpw 2y ago
  Cross post from the blog comments. Since you asked whether there's other solutions... I think it's worth mentioning that there is a GraphQL project which has worked to address every single point elucidated here. Of course whether the framework's conventions satisfy your tastes and sensibilities is an entirely different story. The project had at least an answer if not the answer to every gripe listed in this article by the end of 2022. Despite having basically solved all these issues two years ago, there's been a consistent stream of articles, videos, and podcasts like this one claiming that GraphQL is too complex and the GraphQL ecosystem doesn't provide any tooling or support for managing these complexities. The great irony is that the framework in question is now pivoting away from GraphQL. Seemingly no one wanted to use a GraphQL framework. But why? Whenever someone learned about the framework, they would say to themselves: "Well I don't want to use a GraphQL framework since GraphQL has all these problems like auth and caching and rate limiting and performance. It's just too complex so I'll avoid any frameworks that use GraphQL." They would never seem to realize that the very framework they were refusing to use was literally the answer to the justification provided for why they didn't want to use the framework. Eventually, after having this exact conversation a few hundred times with a few hundred devs, I decided that there's only two ways I could explain what was happening, either: (1) Every time while trying to explain this, all of these developers were experiencing some kind of out of body dissociation not dissimilar to a stroke or brain aneurysm which made it impossible for any semantic meaning to reach them. (2) These developers just didn't like GraphQL and didn't want to use GraphQL. They were making up a bunch of reasons to not use GraphQL but they had no interest in a framework which solved these issues cause the issues weren't the problem, GraphQL itself was the problem. Since I've already spent hundreds or even thousands of hours trying to explain to the open source web dev community how RedwoodJS solves these issues, you'll have to forgive my laziness today and make due with this ChatGPT rebuttal instead of another one of mine. Understanding RedwoodJS in the Context of GraphQL Criticisms: A Detailed Response The blog post raises several valid concerns about GraphQL's use in production environments, particularly around security, performance, and complexity. Here's how RedwoodJS addresses these issues, considering the specifics mentioned in the blog post. 1. Attack Surface - The blog highlights that exposing a query language like GraphQL increases the attack surface of an application, necessitating robust security measures. RedwoodJS leverages GraphQL Armor, which provides built-in protections against common GraphQL vulnerabilities. These include rate limiting, depth limiting, and cost analysis to prevent overly complex queries. Additionally, RedwoodJS uses Envelop plugins for enhanced security measures, such as blocking field suggestions and masking errors, which are essential to prevent information leakage and mitigate potential attacks. 2. Authorization - GraphQL's flexibility can lead to challenges in properly authorizing access to different fields based on context. RedwoodJS integrates authorization directly into the schema using directives like `requireAuth` and `skipAuth`. This ensures that each query and mutation can enforce authentication and role-based access control efficiently. By embedding these security checks into the GraphQL schema, RedwoodJS helps developers avoid the pitfalls of broken access control. 3. Rate Limiting - The blog points out that GraphQL queries can vary significantly in complexity, making it challenging to implement effective rate limiting. RedwoodJS includes mechanisms to estimate and limit query complexity. It supports configurations to set maximum query depth and complexity, thus preventing queries that could otherwise lead to server overload. These settings help ensure that the GraphQL server can handle incoming requests without being overwhelmed, addressing the concern of unpredictable query costs. 4. Query Parsing - GraphQL's requirement to parse queries before execution can lead to vulnerabilities if not handled correctly. RedwoodJS mitigates this by implementing limits on query size and the number of operations, ensuring that the parsing process does not lead to excessive memory consumption or server crashes. This approach helps safeguard against denial-of-service attacks that exploit query parsing vulnerabilities. 5. Performance - The blog mentions issues like the N+1 problem and challenges with HTTP caching in GraphQL. RedwoodJS uses the Dataloader pattern to batch and cache database requests, effectively mitigating the N+1 problem. By ensuring efficient data fetching mechanisms, RedwoodJS maintains performance even with complex queries. Additionally, while HTTP caching is not inherently compatible with GraphQL, RedwoodJS’s structure and client-server interactions are designed to minimize redundant data fetching. 6. Complexity - GraphQL's flexibility can lead to increased complexity in codebases, making it harder to maintain and debug. RedwoodJS aims to simplify the development process by integrating various tools and abstractions that reduce boilerplate code. The framework's philosophy of convention over configuration helps maintain a clean and manageable codebase. Moreover, the built-in support for Cells (components that handle data fetching, rendering, and updating) abstracts much of the complexity away from developers, allowing them to focus on business logic rather than the intricacies of GraphQL. 7. Conclusion - RedwoodJS addresses many of the concerns raised in the blog post through its robust tooling and thoughtful abstractions. By integrating security measures, optimizing for performance, and simplifying the developer experience, RedwoodJS presents a compelling solution for building modern web applications with GraphQL. While the criticisms of GraphQL are valid, RedwoodJS's approach demonstrates that with the right framework, many of these issues can be effectively mitigated, making GraphQL a viable choice for many projects.
• tonyspiro 2y ago
  At Cosmic, we released our latest API version without a GraphQL option in favor of a declarative REST API using `props` https://www.cosmicjs.com/docs/api/objects#get-objects https://www.cosmicjs.com/docs/api/objects#get-objects.
• Gelob 2y ago
  i was over graphql when it started. REST was fine
• hackergary 2y ago
  Have OP heard of Hasura? Majority of issues raised about graphql are solved problems there, and with free CRUD to start Skill issue. REST serverless business logic on top and graphql is great