I like it because it can inflate my invoices. It makes projects last longer but at least i amuse myself when people write gql injections without knowing what they are. But otherwise i find it like yet another fashion tool, a symptom of engineering for the sake of engineering.

Used it in multiple companies, never said "Wow this is great!" - always said "fuck this would be 10x simpler in REST".

The only benefit I have personally experienced is that since we have mobile apps more often than not with Apollo, having the graphql for both mobile _and_ web react is nice.

But with Phoenix Liveview that benefit quickly erodes for me. I say good riddance.

I think you have to ask yourself "compared to what?".

Compared to REST, I would argue auto-generated GraphQL clients are superior (compared to auto-generated REST clients based on something like OpenAPI).

Compared to gRPC, I think it has the advantage that it's much easier to use in the browser and many people seem to prefer text-based protocols for debugability.

What are you comparing it to?

I'm very happy with GraphQL. We use it mainly for APIs that are consumed by several clients (web app, mobile app, other services).

The main benefit to us is that it's a huge time saver. There is almost no similar/duplicated code for similar operations (for example search, list and get operations). It's also very easy to write a generic API once, without thinking to much about how the clients will use it, and have it used in ways that weren't anticipated at the time it was written.

It's also pretty easy to have the API made of entities that are always the same, rather than having routes that return slightly different data.

Another benefit is that the default / basic tooling works well and with no setup. The playground works, it's easy to generate idiomatic clients in many languages, which is not really the case with openapi or grpc.

However, although I have no data to back this up, I feel that the adoption is not that high, and more advanced or unusual tooling doesn't exist or isn't very good or progressing.

Another problem is that developers don't seem to grasp the best practices intuitively and the docs don't make it very clear what they are, but it's necessary to use them to have a useful API and not a slow, more complicated version of REST.

Like most technologies it depends on how you're using it. When I first starting working in GraphQL, paired with a React frontend I used it in an a similar way to REST, pull the data and then do all the logic of what to display on the frontend.

For me I saw the most benefit when I used the schema to define what to display in the frontend, all the logic of what to display is done on the server and my frontend just becomes simple components that render the pulled schema.

GraphQL doesn't allow for recursive types.

This limitation cropped up in a project and was a frustrating (re)discovery. You have to pick a maximum depth and explicitly define that depth.

It abuses POST. No way to tell by a quick glance at the network tab the purpose of a request.

Whichever team controls the implementation of the resolvers decides the return structure which may be less than ideal for the front end team consuming the gql response so a good bit of additional mapping over the response is often necessary.

GQL types are yet another type system I have to learn. I'm happy to, but compared to TypeScript, the GQL type system feels very lacking. To be fair, most type systems feel lacking compared to the TypeScript type system (its so insanely flexible and expressive).

It's very easy to get to a point of a GQL query that makes so many sub queries that the single request takes a long time.

Overall lots of foot guns. I much prefer a REST api and best yet an SDK.

Others have also pointed out GQL can't take advantage of browser caches which is a big UX loss.

I never got the hype around it but others like it so I'm glad it exists for them.

I like it conceptually, but I never actually need it... So yeah.

Implemented a gql API a few times and it felt like it was more efficient than a typical REST API with all the caching and flexibility, as well as feeling more functional because of the handlers. That said, it's not that much better and many apps simply don't need it. Often it's okay to just have a "gimme everything whenever I want it" endpoint that sends 100KB of data.

I'd say graphql is useful when you're worried about requests killing your server.

Been using it the past 3 years, the only form it's been likeable for me was when it's provided for through Hasura/nhost.

No apollo, no prisma, just plain strings in graphql format sent with fetch to a Hasura endpoint hosted by nhost. Automatically built resolvers, great low-code admin UI, easy query building, open source, and builds off of Postgres. It's actually been so effective it's hard to go back to anything else, including Supabase.

In my company, we are building a set of monolith applications based on frontend and backend modules that we can compose (Spring jars and React npm packages). As the maintainer of several of those modules, I don't know how my modules will be integrated in each monolith and I don't know exactly how all the complete frontend of each monolith will interact with each API.

Having the ability to define small schemas for each module gives us a great way to communicate the contract provided by a backend module and the parts of the API required by its associated frontend module.

It can be extended very easily and it gives each monolith the ability to ask for anything they want. On top of that we are using a ton of subscriptions so having the ability to use a common language even for the websocket parts is great.

So in the end, the ability to request anything from the API, the simplicity to extend and compose APIs and the support for subscriptions are features that we would have needed in REST which are "included" in GraphQL.

Here is a different perspective: I like GraphQL because it helps with communicating with other developers. I have lost count of the hours I spent trying to understand a REST API or find where the docs for the REST API are... Sometimes people just add an endpoint and that's that.

With GraphQL, there is a minimum of communication that it is done by the specs and the choices of the frameworks. There are some costs and downsides but for me they are definitively worth it.

The main (and only) criticism I’ve ever heard about graphql in the companies I worked for was that it is very js-oriented all the best libs/frameworks for it are for react frontend / node server mostly.

Backend scala / php devs looked at it with distaste in their eyes, coming up with various reasons why its not a good idea.

And to be fair with tools like openapi / grpc a lot of the benefits of graphql can be replicated.

Even if they are clumsy and fragmented compared to it in my eyes, they still work well enough and keep devs in all camps happy enough, and compromise as they say is “when everyone is equally unhappy”.

Now placed in situations like this I am usually forced to reimplement graphql tooling with the chosen api tech (for example https://github.com/ovotech/laminar) and if me as a single dev could do it, then I’d wager if there was stronger tech leadership, all the other tech tribes could just smooth the edges that they didn’t like for using graphql in their respective languages … but sadly that has not been my experience.

I like it on paper.

In practice, not so much but mostly due to teams not using it properly or leveraging it in a way that actually makes sense. I've seen teams implement gql for something that was used by 1 consumer (another service) that asked for the entire fields in payload anyway.. at least someone got promoted (I would not have promoted them for using the wrong tool for the job, when the right tool would have allowed them to ship faster).

I think that it's one solution where there could be a much better one.

I use go with ent and the gql extension. The way it works, having hooks and privacy extensions is just so lovely. But querying is rather painful for me. It requires an additional tool, because I'm not used to the syntax. It feels very non-intuitive, but I'm rather at the beginning of it, so it's a me thing.

I was thinking why not just pure SQL queries as an alternative? All it would require is a proper filtering/security middleware.

> Likewise, for much larger more complex projects some of the benefits you can get out of GraphQL can warrant the use of it. But there is a massive gap in the middle where it just seems unnecessary.

I'd say it's optimized for a medium complexity API, in terms of types at least. If you don't know the types in advance, because the users can customize fields somehow, then you can't make a particularly useful GraphQL schema.

There is an underlying assumption that you will have runtime stable objects being queried/mutated.

I was extremely skeptical for years. I've been using it daily for 6 months and I'm surprised how much I like it.

Maybe I was bad at defining REST interfaces. But the interface-definition-language aspect of GQL has been invaluable. It's type safety across the network boundary.

Our server side library auto generates DTO structs to satisfy the schema resolvers. It just removes a lot of boilerplate work when adding routes or new return types.

I've only ever found use in GraphQL when it is paired with other technology. Namely Relay (and to some degree Apollo although I'm not as deeply familiar with it as I am with Relay).

Being able to co-locate data queries with components in React has been a huge game changer for me when writing reasonably complex frontend apps. However, GraphQL on its own never struck me as being any more beneficial than Rest.

After the initial hype and adoption, the middle managers who don't code still love it. Every other developer hates it.

Pretty much like Redux or Facebook's ridiculous architecture before that (flux? Something?)

I hear to more and more React and next.js hate everyday as well.

Hopefully this is a sign we're ready for the next great thing in frontend.

Not sure what it will be; personally I moved all the projects I can to solid start.

>I have felt strongly that we would have been better off with a more boring approach like REST

What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.

I don't. Not because of the idea of itself (I think the idea is good), but because of the implementation: we need yet another layer of abstraction to make it happen.

I would use GraphQL if it were natively supported (just like GET/POST/PATCH is, so no libraries on top needed).

I use GraphQL, React (concurrent mode) and Relay (hooks version) in a front end app of reasonable complexity and this combo makes fetching data and managing fetched data very ergonomic and cut down on a lot of the usual boilerplate (loading state tracker etc).

It actually has a very narrow use - traffic heavy (mostly end user) clients with complex data to fetch. I.e. facebook.

But then you got cargo cult thing and now we get what we get.

On a positive side - it reduces unemployment :)

I dislike REST more than I dislike GraphQL. I sometimes use REST for tiny simple APIs but I rather use GraphQL than thinking about the best RESTFul API design to do something.

I honestly haven’t seen the need for it. I’ve worked with it several times, and both times it felt like extra overhead.

I have never used it on a large project. I have never liked it for anything I have tried to use it for.