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?
After 6 years, I'm over GraphQL
291–300 of 721 posts
Re: After 6 years, I'm over GraphQL
#292Earlier quoted context omitted.
That backend engineer wrote a single SQL query that joined some tables, ensured indices were used, and always executed in In graphql land you'd be doing multiple SQL queries, "joining" in the API layer, and spending 50ms per API call.
The entire point of graphql servers is that they're basically ORMs (or use an underlying ORM) that turn complex nesting into a single query's worth of joins. It won't beat hand-crafted sql from an expert, but if that's your preferred approach, debates on the relative merits of different query frameworks are all academic to you anyway.
I've never seen this kind of graphql server implementation that can automatically boil down a complex nested query to sensible SQL. It sounds like the best of both worlds. Do you have links?
Re: After 6 years, I'm over GraphQL
#293Additional 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 eve…
* 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 th…
In my experience, nothing other than nullable DB fields should be nullable in the GQL schema. Everything else like inter-service problems, auth problems, etc, should be modeled as “result boxes” via union types (somewhat equivalent to Maybe/Optional types). This lets your schema model possible failure cases via strong types without ambiguity and results in resilient front-end code.
Note that the error types added to the union should only be as granular as relevant to the client. Most places will be just Foo | FooNotFound | FooError because your UI doesn’t care why there was an error and you don’t want to unnecessarily leak backend info when it’s not relevant.
I wish this was more strongly recommended in the GQL org docs, because so many people learn it the hard way and migrating is not easy.
Re: After 6 years, I'm over GraphQL
#294Earlier quoted context omitted.
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?
Because receiving unexpected data is a signal you rarely want to ignore in programming. Doesn’t matter whether you’re gonna use it or not.
No, that's an important facet of compatibility. If a change is purely additive, existing clients will keep working, something the industry has basically forgotten all about, it seems.
Re: After 6 years, I'm over GraphQL
#295I started at the same conclusion of using OpenAPI and never ventured into GraphQL cause I only had one client.
Re: After 6 years, I'm over GraphQL
#296Earlier quoted context omitted.
> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…
JSON winning over XML is like saying CSV won over MySQL. They aren't equivalent. Much like CSV, JSON isn't particularly standardised and different parsers and writers will do different things in some situations. Usually it doesn't matter, but when it does you're probably in for a lot of pain. If you handle structured data and the structures might change over time, JSON isn't a good fit. Maybe you'll opt for JSON Sche…
What's missing in ECMA-404? Never had a problem with JSON parsers or writers, using it all day every day for decades. It's crappy in some ways, sure, like lack of full floating point support, but standardization is not an issue.
XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexity.
Re: After 6 years, I'm over GraphQL
#297Just 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.
Re: After 6 years, I'm over GraphQL
#298What 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,…
To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file.
It makes UI changes much much easier to deal with.
Re: After 6 years, I'm over GraphQL
#299I'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…
OpenAPI can do graphs too, since you can put in refs to objects that can themselves have refs to other objects, possibly recursively.
Re: After 6 years, I'm over GraphQL
#300Earlier quoted context omitted.
The entire point of graphql servers is that they're basically ORMs (or use an underlying ORM) that turn complex nesting into a single query's worth of joins. It won't beat hand-crafted sql from an expert, but if that's your preferred approach, debates on the relative merits of different query frameworks are all academic to you anyway.
I've never seen this kind of graphql server implementation that can automatically boil down a complex nested query to sensible SQL. It sounds like the best of both worlds. Do you have links?
Typically libraries use a Dataloader + ORM to implement this which gets you pretty far, outside of that some libs like Strawberry with automatically optimize your queries for you if you return Django ORM Querysets.
Any query you were going to build and serve with Rest can be made with these two methods or even a raw dataloader and manual SQL string.