re:#1 Is there a meaningful difference between GraphQl and OpenAPI here?

Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all

▲

JasonSage 2 days ago | parent [-]

> Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all

Right, so if you take away the resolver composition (this is graph composition and not route federation), you can do the same things with a similar amount of effort in REST. This is no longer a GraphQL vs REST conversation, it's an acknowledgement that if you don't want any of the benefits you won't get any of the benefits.

▲

verdverm 2 days ago | parent [-]

There are pros & cons to GraphQL resolver composition, not just benefits.

It is that very compositional graph resolving that makes many see it as overly complex, not as a benefit, but as a detriment. You seem to imply that the benefit is guaranteed and that graph resolving cannot be done within a REST handler, which it can be, but it's much simpler and easier to reason about. I'm still going to go get the same data, but with less complexity and reasoning overhead than using the resolver composition concept from GraphQL.

Is resolver composition really that different from function composition?

▲

JasonSage a day ago | parent [-]

Local non-utility does not imply global non-value. Of course there's costs and benefits, but it's hard to have a conversation with good-faith comparison using "many see it as overly complex" -- this is an analysis that completely ignores problem-fit, which you then want to generalize onto all usage.

	▲	verdverm 15 hours ago \| parent [-]
		People can still draw generalizations about a piece of technology that hold true regardless context or problem fit One of those conclusions is that GraphQL is more complex than REST without commensurate ROI