search

wundergraph / Hypermedia-GraphQL

Hypermedia GraphQL RFC
6 stars 0 forks source link

I think this needs explanation #1

Open jsshapiro opened 3 years ago

jsshapiro commented 3 years ago

This may be a great idea, but it's impossible to tell based on what is here. It needs an English-language explanation of what resources and actions are and what they are for.

GraphQL explicitly blurs the distinction between fields and methods. What is accomplished here with actions that cannot already be accomplished with fields?

What is it, exactly, that makes this "HyperMedia"?

If I'm understanding this spec correctly, it doesn't look like you are adding anything that cannot be accomplished better in an Interface, and you are giving up most (all?) of the static typing advantages of GraphQL. The thing that is missing in GraphQL to make this more convenient is that items in an interface need to be re-keyed in every type that implements the interface. I believe there is already an RFC proposing to remove that requirement, and I'm pretty sure you'd be a hero if you pushed that RFC to acceptance.

Finally, what is here that requires a change to the GraphQL spec?

jensneuse commented 3 years ago

I'm working on an explanation + blog post to explain the motivation.

What is accomplished here with actions that cannot already be accomplished with fields?

It's not about the actual implementation. That's just an idea. I'm not sure how it will look like in the end. The problem I'm trying to address is that there's currently no standardised way for a client to understand what they can do with a representation like e.g. a shopping cart.

If I'm understanding this spec correctly, it doesn't look like you are adding anything that cannot be accomplished better in an Interface, and you are giving up most (all?) of the static typing advantages of GraphQL.

This seems to be a misunderstanding. Quite the opposite is the idea. Currently, you can pass an ID to a mutation to "checkout" a cart. There's no way to say this ID must come from an actual shopping cart.

The thing that is missing in GraphQL to make this more convenient is that items in an interface need to be re-keyed in every type that implements the interface. I believe there is already an RFC proposing to remove that requirement, and I'm pretty sure you'd be a hero if you pushed that RFC to acceptance.

Do you have a link?

Finally, what is here that requires a change to the GraphQL spec?

I'm not proposing any changes to the spec. I'd like to find a common spec to define Hypermedia GraphQL APIs. If we can agree on one way of defining the schema, it's possible to generate clients based on this.

jsshapiro commented 3 years ago

Understanding what you are trying to do makes it a lot easier to be helpful. :-) Still not sure what this has to do with HyperMedia. How much of what you are trying to achieve can be handled by schema introspection?

jensneuse commented 3 years ago

Understanding what you are trying to do makes it a lot easier to be helpful. :-) Still not sure what this has to do with HyperMedia. How much of what you are trying to achieve can be handled by schema introspection?

If you introspect a standard GraphQL Server, the response doesn't tell a client anything about the connections between a response and possible next mutations.

The idea of Hypermedia is that you go to a landing page, follow a link, and this link contains information on what could be done next, e.g. more links, or actions.

I want to make this pattern available to GraphQL.

  1. Go to the landing page (introspection Query)
  2. Follow a link (Query)
  3. React based on the actions in the response (actions -> mutation)

So what I'm trying to do is find a common spec to add state transitions to GraphQL so that you have to have less business logic in the client and more consistent behaviour.