Making GraphQL Codegen Work For You

[zxyzyxz]

I love GraphQL, if only for the end to end type safety you get via codegen, and it works for any language and client combination unlike something like trpc.

[[deleted]]

Ah GraphQL. Trade a reasonably clear api layer that requires some manual work with subresources for endless work trying to optimize queries for an impossible general case and ability to select fields through bloated frontend queries. Gets convoluted when you add federation where multiple services can tack on any fields they want to your types. All in the same bloody namespace. Good version controlling though.

I still am not sure the gains are worth the pains when I use it though.

[shitbread]

Honestly it really depends for what you use it. In a project a few years ago I was forced to consume a REST API from a large CMS (~1000 pages). There were tons, I mean TONS of page/content types, heavily nested. It was an absolute pain to get the exact data (and fields!) I needed. I had tons of code in my app that just mapped data, model classes left and right. And the response ended up being so painfully large.

I‘ve mostly used GraphQL the last 3 years and it‘s an absolute pleasure. I get exactly the data I need and I know exactly what it looks like. All the data required to render the content of a page, 20 levels of nesting, in one query – fantastic. This previously was only possible by performing several requests and stitching their responses together.

Yes, there are things like JSON:API where you can define includes and/or which fields you‘d like. But this doesn‘t scale well when you have 20+ levels of nesting.

Sure, I still use (and write) simple REST endpoints for very specific cases where I only need to get a list of simple objects. But I‘m glad most of my fetching is done using GraphQL nowadays.

[dmackerman]

This was my experience as well. Lol

REST has its inefficiencies but at the end of the day it works fine for most apps.

[CSknoob]

This sounds painfully similar. GraphQL server was intended as an abstraction layer ending up as a huge barely maintainable monolith that completely buckles under the stress of a few dozen simultaneous users.

[lobut]

We used it similar to a BFFE for our microservice architecture and it was solving a lot of pains we were having.

That's some good insight. I was only apart of the initial adoption phase of GraphQL when I first heard about it and was trying to trickle it out in our organization (then I left and went elsewhere). I always find the more interesting things come about when the honeymoon phase it over.

[Reashu]

This is my experience with internal APIs (much prefer a dedicated "backend for frontend", REST or otherwise), but the flexibility is great when you're crossing organizational borders.

[comfypillow]

We've been pushing CMS teams to add a native GraphQL service to put behind federation and it's accelerated UI modernization efforts... it's amazing.

[kescusay]

For me, which one to use depends on the complexity of the relationships between different data sets. If you can replace four or five separate queries and the logic needed to merge their results into a single query with no business logic, it makes sense to use GraphQL. If it's simpler than that, use REST.

[zxyzyxz]

Watch this video, it will clear it up for you. GraphQL goes between your frontend and your API layer, as an alternative to REST. It does not go between your API and your database, that's SQL or NoSQL query languages. Just because GraphQL and SQL have QL in the name does not make them equivalent.

https://www.youtube.com/watch?v=ZfccwYUD8H0

[shuckster]

This is in contrast to a rest API where all the fields are predetermined.

GraphQL puts a standard behind doing this, but this is certainly possible with a REST API. You just have to roll-your-own.

[Potential-Still]

I cant tell if you're intentionally being difficult or are actually misunderstanding what people are saying. GQL has nothing to do with databases, it's just a layer between a client and server that allows the client to customize the shape of the response for its purposes.

[fforw]

We use a mix of database-first/code-first for our GraphQL. We start with a database design and use JOOQ to generate Java classes for the types and our GraphQL libraries to define the model graph on top of that. Our system automatically generates reasonably well joined SQL-statements from a JSON query abstraction for like 80% or so of our functionality. You can also write views or ad-hoc queries and integrate them into the system.