3 ms·

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 ty

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.
- chuckadams 2y ago
  > (auth, rate limiting, error handling and validation stick out particularly) I got all that for free with API Platform because it's based on Symfony. Ironically it's the graphql implementation that's primitive [1] -- but rock solid, so it won out, and being a rank newbie at GQL when I started, it was probably best I was stuck with the basics. The JS backend world is a lot more ad hoc than the modern PHP world, so I can picture a lot more nightmare integration scenarios there. Besides, I'd probably prefer using tRPC + zod for my next all-TS project. -- [1] - It's actually pretty sophisticated underneath, but the code is a loosely-documented architectural maze, so yeah.
drpossum 2y ago
> used it in a small project, and liked almost every bit of it This is the difference
- Hamuko 2y ago
  I don't know, I used GraphQL in a small project and I absolutely hated it. I mean, it was definitely workable, but I just absolutely hated writing those queries. Why am I having to write these again? It's not my website, so why am I in charge of writing the API?
- chuckadams 2y ago
  Perhaps, but isn't everybody saying it's strictly for the Billion-User Big Dogs? I admit I'm a small-timer nowadays, but having been a cog in a couple mega-corporate machines, I would have walked over my grandmother to get the strongly-typed tooling I get with graphql.

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.

chuckadams 2y ago
> (auth, rate limiting, error handling and validation stick out particularly) I got all that for free with API Platform because it's based on Symfony. Ironically it's the graphql implementation that's primitive [1] -- but rock solid, so it won out, and being a rank newbie at GQL when I started, it was probably best I was stuck with the basics. The JS backend world is a lot more ad hoc than the modern PHP world, so I can picture a lot more nightmare integration scenarios there. Besides, I'd probably prefer using tRPC + zod for my next all-TS project. -- [1] - It's actually pretty sophisticated underneath, but the code is a loosely-documented architectural maze, so yeah.

drpossum 2y ago

> used it in a small project, and liked almost every bit of it This is the difference

Hamuko 2y ago
I don't know, I used GraphQL in a small project and I absolutely hated it. I mean, it was definitely workable, but I just absolutely hated writing those queries. Why am I having to write these again? It's not my website, so why am I in charge of writing the API?
chuckadams 2y ago
Perhaps, but isn't everybody saying it's strictly for the Billion-User Big Dogs? I admit I'm a small-timer nowadays, but having been a cog in a couple mega-corporate machines, I would have walked over my grandmother to get the strongly-typed tooling I get with graphql.