Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL and the Beads on a String

blog.luccasiau.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: GraphQL and the Beads on a String

#41

Post by akio »

Omerd6 wrote: post #19

does merging all of your api calls to a single one means that the slowest request is a bottle neck? when splitting your request the user can view his profile picture before the main content finished loading. this cam hurt user experience

You can specify parts of a query should be sent in subsequent responses with the @defer directive, and your client and server libraries will handle the rest for you.

Server side:

https://the-guild.dev/graphql/yoga-server/docs/features/defe...

https://www.apollographql.com/docs/router/executing-operatio...

Client side:

https://www.apollographql.com/docs/react/data/defer

https://relay.dev/docs/next/glossary/#defer

Re: GraphQL and the Beads on a String

#42

Post by Jonovono »

timr wrote: post #38
Jonovono wrote: post #36

Earlier quoted context omitted.

haha, I don't disagree. What makes it "simple" is the code generation, abstractions etc thats going on. But ya, thats also what makes it complex. At the end of the day tho, I feel like the complexity is going to be somewhere. Especially for a small team (single dev), I don't know any other better system. Either you will have complexity maintaining a bunch of endpoints, keeping track of where each one is used, what is…

> Either you will have complexity maintaining a bunch of endpoints, keeping track of where each one is used, what is returned, where the contracts are defined, writing tests to make sure nothing breaks, .... Sure, you might not have much abstraction and it will be cleaner that way, but it will be a nightmare to maintain, especially in the phase when you are moving fast and breaking things as you find market fit Yeah,…

That's fair. In my experience, once the endpoints get above a handful id rather not have to keep that all in working memory. And say you have several clients: android, ios, web, internal tooling, cli, rebase, etc. You make a change to 1 endpoint, now you have to remember everywhere you consume that client? Even 5 endpoints, 5 clients things are getting complex to keep in your head.

I'd much rather if I make a change to an endpoint, my project literally won't build and my IDE yells at me. I can make sweeping changes and go to sleep knowing I didn't mess anything up. And I know if I bring another engineer on, they can make sweeping (or tiny) changes and not have to know all of the places that consume that.

I should also note that WG doesn't require graphql. I have a few graphql operations, but you could use it completely without any graphql operations.

Re: GraphQL and the Beads on a String

#43

Post by Jonovono »

owlstuffing wrote: post #28
Jonovono wrote: post #3

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 system…

Using manifold-graphql[1], at least on the client side, has had a similar productivity gain here. 1. https://github.com/manifold-systems/manifold/tree/master/man...

I'll take a look. What I like about WG is with the defined operations on the server, I then get a typed client I can use in Typescript, Openapi (which I can use to generate clients for ios, android, etc), I get postman collection. Pretty much any client I want to consume my api from, I have a client ready to go. Now, I make changes to any of my operations, my clients will complain.

Re: GraphQL and the Beads on a String

#44

Post by timr »

Jonovono wrote: post #42
timr wrote: post #38

Earlier quoted context omitted.

> Either you will have complexity maintaining a bunch of endpoints, keeping track of where each one is used, what is returned, where the contracts are defined, writing tests to make sure nothing breaks, .... Sure, you might not have much abstraction and it will be cleaner that way, but it will be a nightmare to maintain, especially in the phase when you are moving fast and breaking things as you find market fit Yeah,…

That's fair. In my experience, once the endpoints get above a handful id rather not have to keep that all in working memory. And say you have several clients: android, ios, web, internal tooling, cli, rebase, etc. You make a change to 1 endpoint, now you have to remember everywhere you consume that client? Even 5 endpoints, 5 clients things are getting complex to keep in your head. I'd much rather if I make a change…

> I'd much rather if I make a change to an endpoint, my project literally won't build and my IDE yells at me. I can make sweeping changes and go to sleep knowing I didn't mess anything up. And I know if I bring another engineer on, they can make sweeping (or tiny) changes and not have to know all of the places that consume that.

I think you're making an allusion to GQL typing here, which I grant. A big downside of REST+JSON is that you've pushed most of the "interface contract" to the structure of the JSON file.

> I should also note that WG doesn't require graphql.

Sure. The common element to both (for me) is the layering of abstractions that hide what's really going on.

Re: GraphQL and the Beads on a String

#45

Post by Jonovono »

timr wrote: post #44
Jonovono wrote: post #42

Earlier quoted context omitted.

That's fair. In my experience, once the endpoints get above a handful id rather not have to keep that all in working memory. And say you have several clients: android, ios, web, internal tooling, cli, rebase, etc. You make a change to 1 endpoint, now you have to remember everywhere you consume that client? Even 5 endpoints, 5 clients things are getting complex to keep in your head. I'd much rather if I make a change…

> I'd much rather if I make a change to an endpoint, my project literally won't build and my IDE yells at me. I can make sweeping changes and go to sleep knowing I didn't mess anything up. And I know if I bring another engineer on, they can make sweeping (or tiny) changes and not have to know all of the places that consume that. I think you're making an allusion to GQL typing here, which I grant. A big downside of RE…

It's not GQL typing. None of my clients make GQL requests. I don't have apollo or any other junky Graphql client anywhere in my clients. All my clients still just make simple rest rpc requests. The benefit is that I have generated these clients to make these requests from simple typescript operations, or graphql operations (which the GQL is just specified on the server)

Ya, for rest and json that was my challenge. I liked the idea of openapi, but manually creating openapi docs was just not much fun.

If you are really curious about WG approach this is a good intro: https://www.youtube.com/watch?v=m3YrZav5-CU. They have some contrarian takes within the graphql community

Re: GraphQL and the Beads on a String

#46

Post by owlstuffing »

Jonovono wrote: post #43
owlstuffing wrote: post #28

Earlier quoted context omitted.

Using manifold-graphql[1], at least on the client side, has had a similar productivity gain here. 1. https://github.com/manifold-systems/manifold/tree/master/man...

I'll take a look. What I like about WG is with the defined operations on the server, I then get a typed client I can use in Typescript, Openapi (which I can use to generate clients for ios, android, etc), I get postman collection. Pretty much any client I want to consume my api from, I have a client ready to go. Now, I make changes to any of my operations, my clients will complain.

manifold does the same by working directly from graphql, no codegen steps to screw sync. if changes are made to graphql definitions, the client fails to compile.

Re: GraphQL and the Beads on a String

#47

Post by Jonovono »

owlstuffing wrote: post #46
Jonovono wrote: post #43

Earlier quoted context omitted.

I'll take a look. What I like about WG is with the defined operations on the server, I then get a typed client I can use in Typescript, Openapi (which I can use to generate clients for ios, android, etc), I get postman collection. Pretty much any client I want to consume my api from, I have a client ready to go. Now, I make changes to any of my operations, my clients will complain.

manifold does the same by working directly from graphql, no codegen steps to screw sync. if changes are made to graphql definitions, the client fails to compile.

ah, sounds interesting thanks. Will give it a look!

Re: GraphQL and the Beads on a String

#48

Post by 015a »

bryanrasmussen wrote: post #14
015a wrote: post #6

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…

>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 n…

If I insinuated that GraphQL is dead, that wasn't my intention. It definitely has fallen out of the spotlight, however. I'd point to e.g. looking at statistically how many APIs ran by major internet companies are available over GraphQL versus more traditional REST or RPC. Github is the only one that springs to mind, and its available in addition to a REST API.

Even Meta has a "Graph API" that is not GraphQL (https://developers.facebook.com/docs/graph-api/overview) (they may have an odd GraphQL API here and there; I am not deeply familiar with the entirety of their offering, and I don't want to insinuate such; just that they don't seem to rave about it front and center if they do, and instead invented a second, separate thing).

I interact with a GraphQL API among much smaller integration partners maybe once or twice a year; versus dozens of REST APIs. They're definitely around, people definitely still use it (my company has one!), but arguing that its the standard way frontend APIs are written feels very detached from reality; and maybe you really are special.

Re: GraphQL and the Beads on a String

#49

Post by dalyons »

jongjong wrote: post #27
code_biologist wrote: post #16

Earlier quoted context omitted.

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 sp…

> 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. I don't buy this argument. Imagine if an airplane manufacturer had the same philosophy. "We can't just substitute that component because it wouldn't fit the existing frame... Oh but wait, we can't just change the frame or the new component to make it fit…

Software isn’t nearly as expensive as building airplanes, and the cost of being wrong is infinitely lower. That’s why we build it fast, and iterate quick. It’s not a good comparison.

Re: GraphQL and the Beads on a String

#50

Post by apimade »

tshaddox wrote: post #40
apimade wrote: post #34

GraphQL is great for public data and endpoints. Or endpoints that are completely system to system, single-tenant, “we can give the user all the data we hold” integrations. That is, internal integrations where authorization is handled elsewhere. Exposing a GraphQL endpoint has the same issues as exposing a DB. You need to define granularity of access to each individual table, column and row for each user. I’ve yet to…

How does REST solve this any better? As soon as you have certain entities or fields which are visible only to certain subsets of users, surely the problem complexity is essentially the same.

In theory REST doesn’t, in practice it does. The reason why is because most RESTful interfaces are built and deployed separately. You don’t throw an interface on top of a data model and presto, you’ve accidentally exposed your customer data to the internet.

The other aspect is with REST the interface is strictly defined. There’s no unknown data being disclosed, you’ve defined the resource and understand the authorization required by building it in the first place. Yes, mistakes are made by engineers who don’t understand what PII is or don’t care what the access control for the endpoint looks like, but at least you can spend time actually scoping it and defining what that looks like.

How do you threat model a constantly changing database? You could throw flags on fields and have that tie in with your GQL orchestration lib/tooling, but that’s something that very, very few organisations can get right.

Not even 1%, I’d say maybe less than 100 in the world.

Post reply on HN