4 ms·

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 k

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.
mdaniel 2y ago
I am for sure no graphql ninja but I believe what you are describing is achievable via the introspection call, which the sibling comment hints at when mentioning the schema but I'm saying that's a runtime call just like any other and thus no "reading" required. I do think that introspection stuff is opt-in because some shops consider it an information leak vector, but for dev/staging I think it's a perfectly fine tradeoff https://graphql.org/learn/introspection/ https://graphql.org/learn/introspection/

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.

mdaniel 2y ago

I am for sure no graphql ninja but I believe what you are describing is achievable via the introspection call, which the sibling comment hints at when mentioning the schema but I'm saying that's a runtime call just like any other and thus no "reading" required. I do think that introspection stuff is opt-in because some shops consider it an information leak vector, but for dev/staging I think it's a perfectly fine tradeoff https://graphql.org/learn/introspection/ https://graphql.org/learn/introspection/