[HN Gopher] GraphQL and the Beads on a String
___________________________________________________________________
GraphQL and the Beads on a String
Author : luccasiau
Score : 20 points
Date : 2024-01-20 21:20 UTC (1 hours ago)
(HTM) web link (blog.luccasiau.com)
(TXT) w3m dump (blog.luccasiau.com)
| eddd-ddde wrote:
| If you need to request multiple REST resources for a single
| "operation", then you don't have enough REST resources defined.
| [1]
|
| Just make another endpoint for getting the whole thing in one go
| and call it a day, don't try to overly generalise your API.
|
| Going even further, your server requests to the database could be
| similar as well, one query to get everything needed, then you
| don't even need to worry about server to database distance!
|
| [1] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-
| hypert...
| rbalicki wrote:
| The problem with REST (or really, any current non GraphQL
| solution) is there is only an implicit link between the
| consumer of a field and the query declaration. So, REST queries
| are append only, especially at large organizations where
| incremental perf improvements are less good than accidentally
| bringing down the site is bad. That's the failure mode of
| specialized REST endpoints that deliver exactly what a given
| view needs.
| eddd-ddde wrote:
| If you require something more explicit, you can totally
| define strict schemas that your API adheres to.
|
| Would you elaborate on "queries are append only"? I fail to
| understand the downside you mention.
|
| If you mean that you can only append to the data you return
| from a resource, you can use versioning to deprecate
| properties on a resource.
| strken wrote:
| "Make another endpoint for getting the whole thing in one go"
| is a pretty good description of what GraphQL _does_. Except
| instead of writing an endpoint in some general purpose language
| you define it declaratively.
| pier25 wrote:
| > _is a pretty good description of what GraphQL does_
|
| Maybe but the implementation is orders of magnitude more
| complex compared to simply making a couple of DB queries and
| then sending a JSON.
| code_biologist wrote:
| My practical experience with that idea is pretty negative, at
| least with any degree of scale (either in how widely used the
| resource in question is or in number of people working on the
| system). I saw a multi-year mess made at a company when the
| widely used `ResourceA` got endpoints for `ResourceAandB` and
| C, and D, and E... for the reasons you mention. Then somebody
| added some fields to make a `ResourceA'` with a specific
| additional feature. Then somebody removed unused fields from
| `ResourceA'` for better performance, creating different
| subsets. We ended up with some `ResourceAandC` things moving to
| the new `A'`, some features did a frontend join with multiple
| queries, some things moved to a new superset resource named
| `ResourceA''`. It was a Cambrian explosion of variants of
| types. Like violence, it ended up being "if one doesn't work,
| just add more."
|
| It's easy to say "don't do that" but shit happens: large legacy
| codebases, social factors, and individual incentives of backend
| and frontend teams with deadlines. GraphQL makes the outcomes
| of these situations a lot more manageable. In that way I think
| of it as a social and organizational technology as much as a
| query technology.
| Jonovono wrote:
| I never really _got_ graphql until I stumbled upon Wundergraph.
| (https://github.com/wundergraph/wundergraph). I have no
| affiliation with them except that I have been building an app
| with it. I'm honestly puzzled how it's not more popular. Maybe
| people are solving these problems in other ways? But I tried out
| a bunch of stuff: Vapor, Supabase, Hasura, firebase, nhost, etc.
| None of it simplifies building complex systems the way WG does.
|
| Once I ship I plan to put together a nice sample repo talking
| about why I like it, but you can see the WIP here of how I use WG
| to build a system with (potentially) multiple databases being
| consumed in a type safe manner from my ios app, nextjs app (and
| anything else)
|
| https://github.com/Jonovono/WGStack
| jensneuse wrote:
| I'm one of the WG founders. Thanks for the mention. In case
| anybody has a question, please ask. (I'm getting a notification
| if you use the term "WunderGraph")
| codetrotter wrote:
| > I'm getting a notification if you use the term
| "WunderGraph"
|
| What happens if I say it three times in a row?
|
| Will it summon you to appear in my geographical proximity?
|
| WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
| SlickStef11 wrote:
| If you say it 3 times, one of the founders will appear
| behind you with a Federetzel
|
| https://twitter.com/meixnertobias/status/170456581402277085
| 7
| jensneuse wrote:
| Say it 5 times and a genie appears who creates you a
| federated Graph of 100 Microservices although a single
| boring monolith would have been enough.
| 015a wrote:
| If the primary selling point of the new technology is something
| like GraphQL's "if your API doesn't have a good single route to
| get the data for this page, GraphQL can synthesize it"; frontend
| just doesn't, in general, iterate at a speed that is such orders-
| of-magnitude higher than how quickly a new API view can be built,
| such that a new structurally-different communications layer is
| necessary.
|
| Additionally; GraphQL _never_ got the community love it needed on
| the backend side to make things hum. Apollo is the only
| organization really pushing it, and they invest something I 'd
| estimate as 10% of their time into thinking about Apollo Server,
| which is in any event JavaScript-only. It turns out, the problems
| GraphQL creates in a system are backend problems; there's some
| really freakin hairy edges in the domains of authorization,
| caching, rate limiting/complexity limiting, even just basic type
| safety, that can only charitably be described as "solved" if you
| consider "some ideas in a twenty page blog post" as a solution.
|
| We also had constant problems educating our customers about
| GraphQL. "No no, you can use any REST client you want, here let
| me show you how to set it up" (two hour education session later).
|
| There really isn't a perfect solution to the problem space. If
| your view is complex enough, synthesizing it JIT in GraphQL is
| just the frontend saying "its your problem now" to the backend,
| and whether the solution to that is "fixing performance
| bottlenecks" or "a new RESTful-ish view API for this screen" for
| the backend team, its still a ticket. If the view is less complex
| than that: making multiple requests isn't the end of the world.
| After all, those two highly predictable, optimized, even cached
| requests may end up being faster than one dynamic and extremely-
| difficult-to-cache GraphQL request.
|
| At the end of the day, I think there's a reason why REST has
| lasted as long as it has, and why it _still_ feels state of the
| art to me. Moving more API capabilities to edge platforms,
| including edge databases, shortens that string of beads quite
| substantially. Server-side rendering is back is in full force.
| There 's other angles this problem is being attacked from.
| bryanrasmussen wrote:
| >Additionally; GraphQL never got the community love it needed
| on the backend side to make things hum.
|
| Ok, well for some reason every project I've been on in the past
| 4-5 years has used GraphQL? What makes me so special?
|
| As I conclude that I am not special I have to go back to what
| my previous position was that GraphQL is pretty much the
| standard way front-enders query nowadays.
|
| That said - the project I am on right now only uses GraphQL for
| querying CommerceTools, and their GraphQL implementation seems
| like someone told a dev hey, we need GraphQL, make our SQL
| backend available over that, and he completed his ticket
| anywhere from 4 hours to 4 days, but certainly not in any
| amount of time to make a solution that had any of the
| advantages of GraphQL in it.
|
| We used to have GraphQL for the part of the project using
| Contentful - but their GraphQL was so problematic we moved to
| their Rest API (I say was because that move was over 1 year
| ago, it would be wrong to say it is bad now - who knows what
| improvements they might have had)
| williamcotton wrote:
| I like the RESTful approach taken by Graphiti:
|
| Single request and response and with a graph of nested
| relationships. This approach lets one still use HTTP GET caching,
| whereas GraphQL hides everything behind a single POST endpoint.
|
| https://www.graphiti.dev/guides/
___________________________________________________________________
(page generated 2024-01-20 23:00 UTC)