Conversation

Notices

1. Embed this notice
   Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 11-Jul-2023 01:45:55 JST Alex Gleason
   Threads is using graphql. No surprise, but interesting to see.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 11-Jul-2023 01:47:56 JST Alex Gleason

     in reply to
     "line_type": "none"
     
     Seems so wrong this is part of the data layer instead of the UI layer. They're not so precious about their API at Facebook. Nobody besides them would want to implement this API. But they aren't intending for anyone to do that, either.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 02:32:26 JST feld

     in reply to
     @alex I’m extremely suspicious of the value proposition of GraphQL.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 11-Jul-2023 02:33:27 JST Alex Gleason

     in reply to

     • feld
     @feld Me too. But Facebook uses it to serve 100 million users, so it must work.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 02:38:13 JST feld

     in reply to
     If I successfully run a business putting rollerskates on horses you can say that it works but not necessarily that it provides value :newlol:
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 02:38:33 JST feld

     in reply to

     • Ako Suminoe :njp:
     basically everything that GraphQL does can be done with REST too, tho.
   • Embed this notice
     Ako Suminoe :njp: (realakosuminoe@poa.st)'s status on Tuesday, 11-Jul-2023 02:38:34 JST Ako Suminoe :njp:

     in reply to

     • feld
     @alex @feld GraphQL is a replacement for REST APIs. It's not about app scalability, but organization scalability. It makes it easier for you to connect multiple frontends to a single backend without the need for SDK development teams.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 02:39:38 JST feld

     in reply to

     • Ako Suminoe :njp:
     • feld
     This matches my opinion of it, having looked at it only a few times and done one tiny thing to communicate with a GraphQL API
     
     https://news.ycombinator.com/item?id=32366759
   • Embed this notice
     Ako Suminoe :njp: (realakosuminoe@poa.st)'s status on Tuesday, 11-Jul-2023 02:57:25 JST Ako Suminoe :njp:

     in reply to

     • feld
     @feld @alex Not really. At least, if you contort a REST API to do what GraphQL can do, it loses the advantages of REST APIs. The singular advantage of a REST API is that they are highly cacheable. The advantage of GraphQL is that it's easier to make querying child objects in a single request, you can add query parameters to a REST API to include specific child objects, but you have to do this specifically for each child object, and it also becomes a new request that can't be cached with the other requests.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 02:57:25 JST feld

     in reply to

     • Ako Suminoe :njp:
     > Not really. At least, if you contort a REST API to do what GraphQL can do, it loses the advantages of REST APIs. The singular advantage of a REST API is that they are highly cacheable.
     
     How do you mean? Design the REST API to allow specifying what fields you want returned, and make it do that. The caching proxy should include the POST parameters when caching the unique response. I could do this with Varnish pretty easily.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 04:03:22 JST feld

     in reply to

     • Ako Suminoe :njp:
     > If you add query parameters to determine what fields get returned, those become separate requests so they can't be cached together.
     
     Yes this would waste more memory on your caching layer, but it's still possible. Keep the TTLs low enough and it shouldn't matter much.
     
     > With REST APIs, I regularly end up making THOUSANDS of individual requests to get all the information that I need
     
     Well, you should be working with your backend team to design APIs that don't require that, but I understand that sometimes you're screwed because "that team" doesn't have the "resources" to work on your problem. That's why this smells like "GraphQL is here to fix the biggest problem with corporate silos"
     
     > while I can pack everything from GQL APIs into a SINGLE request
     
     Like the comments in my HN link point out, now you have a different problem: preventing DoS attacks or queries that are crazy expensive and can cause significant load/crashes of your backend. So you have to add an entire security layer on top of GraphQL to limit size of queries and size of responses because it's as evil as handing out unrestricted SQL access to your backend database(s)... we're just moving the work and responsibility around, really.
   • Embed this notice
     Ako Suminoe :njp: (realakosuminoe@poa.st)'s status on Tuesday, 11-Jul-2023 04:03:23 JST Ako Suminoe :njp:

     in reply to

     • feld
     @feld @alex The advantage of REST API there is that everyone uses the SAME request, so they get cached. If you add query parameters to determine what fields get returned, those become separate requests so they can't be cached together.
     
     /api/my_object and /api/my_object?fields=a,b are two different requests, so the only technical advantage of REST API is gone. All consumers of the API need to be calling /api/my_object for caching to work between those two consumers. The same is true for things like including children and filters.
     
     But including children is by far the best advantage of GraphQL. With a REST API, you would need to custom code a /api/my_object?include=my_child parameter for it to work. It can be done, but it all has to be custom and I hardly ever see it done in practice. GraphQL makes it trivial to not only include children but filter and select fields for them, too.
     
     For a REAL WORLD example, I regularly have to call REST and GQL APIs at work. With REST APIs, I regularly end up making THOUSANDS of individual requests to get all the information that I need, while I can pack everything from GQL APIs into a SINGLE request (plus pagination). The GQL takes a lot less time and is far simpler.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Tuesday, 11-Jul-2023 04:15:04 JST Alex Gleason

     in reply to

     • Ako Suminoe :njp:
     • feld
     @RealAkoSuminoe @feld I wish it was cachable. But when the entity includes stats (like statuses especially) you can only partially cache it.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 05:42:56 JST feld

     in reply to

     • Ako Suminoe :njp:
     > And no, it's not the same as handing out unrestricted access to your DB any more than REST is. It's an alternative way to make APIs, not a SQL replacement.
     
     Here's what I'm talking about, sourced from those HN comments:
     
     >> It's actually worse than that [bad query example in a previous comment], because with graphql you can create a single query which is the moral equivalent of:
     SELECT * FROM master_table LEFT JOIN sub_table LEFT JOIN sub_sub_table LEFT_JOIN sub_sub_sub_table...
     ...which is effectively "dump everything". In a REST environment you'll at least need a lot more individual requests - that's both the blessing and curse.
     
     I do not want that power to exist in an API that I give to any developer, ever.
   • Embed this notice
     Ako Suminoe :njp: (realakosuminoe@poa.st)'s status on Tuesday, 11-Jul-2023 05:42:57 JST Ako Suminoe :njp:

     in reply to

     • feld
     @feld @alex Not my team. They are 3rd party API services.
     
     The tradeoff is between ingesting one query that has a lot of load on the backend and a bunch of queries that each have a smaller load but combined have a greater one. If a query takes too long, the smarter thing to do is to push it into a background job and give the caller a URL to fetch the result later. I don't know if common GQL tooling supports this, but this is the proper solution.
     
     And no, it's not the same as handing out unrestricted access to your DB any more than REST is. It's an alternative way to make APIs, not a SQL replacement.
     
     Edit: GQL also helps resolve the "problem" of corporate silos, even if it wasn't relevant to my specific case. It is a serious issue, and reducing the need for communication between different teams that are in different stages of the SDLC is a very good thing.
   • Embed this notice
     Ako Suminoe :njp: (realakosuminoe@poa.st)'s status on Tuesday, 11-Jul-2023 06:47:18 JST Ako Suminoe :njp:

     in reply to

     • feld
     @feld @alex You should stop taking the commentariat on HN seriously.
     
     Including children in a GQL query do not become the equivalent of arbitrary SQL LEFT JOINs because GQL is NOT A REPLACEMENT FOR SQL. If there is an include available in the GQL spec for your API, it's because you put it there. It doesn't allow random arbirary joins.
   • Embed this notice
     feld (feld@bikeshed.party)'s status on Tuesday, 11-Jul-2023 06:47:18 JST feld

     in reply to

     • Ako Suminoe :njp:
     Thanks for your responses, it's refreshing to get a take from someone who has been in the deep with GraphQL.
     
     One of the other pain points I remember from years ago was that allegedly there wasn't a good way to stop the clients from requesting e.g., limit: 10000000 items. Is this now possible with modern implementations?