4 ms·

The article doesn’t seem to give enough weight to GraphQL: it’s only mentioned in passing even though it solves the waterfall request problem mentioned much lat

The article doesn’t seem to give enough weight to GraphQL: it’s only mentioned in passing even though it solves the waterfall request problem mentioned much later in another context.

tln 4y ago
GraphQL isn't a web framework though. ---- I wonder if GraphQL is destined for the same type of evolution; React was a revelation compared to what came before, hugely popular, with a heavy client library and runtime costs. I see some of those in GraphQL The new wave of svelte and quik etc are faster and lighter, by pre-compiling or rethinking how and when the work is performed
- deleted 4y ago
  [deleted]
- eurasiantiger 4y ago
  You’re right, but for example Apollo is a widely used GraphQL framework for both server and client—yet it was not mentioned.
mcluck 4y ago
Hot take: a lot of usage of GraphQL is terrible and most apps don't need it. For example, I worked at a place where it was a requirement that everything runs through GraphQL. Sure, fine, except then you see that they were making tailor-made resolvers for particular use cases. You wouldn't see multiple different apps or sections of the app pulling from the same endpoint but with trimmed down queries. It was essentially BFF but with a GraphQL middleware because "it's what big companies do." I've had a number of friends say they've seen the same thing. I'm sure when you're working with applications like Facebook and you're using it intelligently, it's great. My experience is that many people don't understand that.
- eurasiantiger 4y ago
  I agree, that is a problem: people forget the ”graph” in GraphQL. It’s too easy to just create new query resolver to resolve that one ticket instead of thinking how data relates to other data and how it could be resolved using that other data. That is ultimately a people problem, however: why doesn’t it click that a ”resolver” is intended to ”resolve” other entities based on fields of the parent entity?

The article doesn’t seem to give enough weight to GraphQL: it’s only mentioned in passing even though it solves the waterfall request problem mentioned much later in another context.

tln 4y ago

GraphQL isn't a web framework though. ---- I wonder if GraphQL is destined for the same type of evolution; React was a revelation compared to what came before, hugely popular, with a heavy client library and runtime costs. I see some of those in GraphQL The new wave of svelte and quik etc are faster and lighter, by pre-compiling or rethinking how and when the work is performed

deleted 4y ago
[deleted]
eurasiantiger 4y ago
You’re right, but for example Apollo is a widely used GraphQL framework for both server and client—yet it was not mentioned.

mcluck 4y ago

Hot take: a lot of usage of GraphQL is terrible and most apps don't need it. For example, I worked at a place where it was a requirement that everything runs through GraphQL. Sure, fine, except then you see that they were making tailor-made resolvers for particular use cases. You wouldn't see multiple different apps or sections of the app pulling from the same endpoint but with trimmed down queries. It was essentially BFF but with a GraphQL middleware because "it's what big companies do." I've had a number of friends say they've seen the same thing. I'm sure when you're working with applications like Facebook and you're using it intelligently, it's great. My experience is that many people don't understand that.

eurasiantiger 4y ago
I agree, that is a problem: people forget the ”graph” in GraphQL. It’s too easy to just create new query resolver to resolve that one ticket instead of thinking how data relates to other data and how it could be resolved using that other data. That is ultimately a people problem, however: why doesn’t it click that a ”resolver” is intended to ”resolve” other entities based on fields of the parent entity?