Edge Weights

[parthradia]

What feature are you missing?

Edge weights (a float value).

Justification: according to the GraphQL spec, we're supposed to think in graphs "all the way down".

Essential to graphs are edge weights, used to specify the strength of a relation between two nodes.

For a lot of modern apps, training weighted relations with ML will play a huge role in providing value for the end user. As such, I think this is essential for Graphcool to at least start thinking about how to implement this ...

How could this feature look like in detail? Tradeoffs?

I honestly need to know more about how Graphcool implements its hosted datastores, and the datastore connectors to spec this out!

[kbrandwijk]

This would be a perfect addition to https://github.com/graphcool/framework/issues/746

[parthradia]

@kbrandwijk until this gets sorted out, what do you think about this workaround?

• With @model observe SQL conventions and create intermediary "edge types".
• For clients, expose a corresponding set of resolvers and associated schema that resolve using @model and "edge types" in desired ways.

[kbrandwijk]

I would go the Gateway route and apply the transformation yourself, until the edge concept becomes a first class citizen. As resolver functions can't return model Types yet, your alternative would be hard to implement at this moment.

I've added it to my list of example ideas: kbrandwijk/graphcool-gateway-examples#1

[parthradia]

Is it not feasible to adopt an approach like this?

https://github.com/graphcool/framework/tree/master/examples/full-example

I'm unclear as to how the gateway route is a better option. It seems that working off this example, I can just lock down the simple API ... but I'm new here so I could be wrong!

[kbrandwijk]

Maybe I misunderstand your proposed approach.

[parthradia]

No worries, just curious as to the benefit of hooking together remote schemas with graphql-tools.

Gateway use cases as stated in the docs:

• Implementing custom queries and mutations with your own GraphQL resolvers.
  • Wrapping an existing API
  • Providing shortcuts to the service's CRUD API
  • Auth workflows
• Transforming & validating incoming data
• Validating IP adresses

It seems only the last bullet can't be accomplished with manipulation of permissions in the graphcool.yml file and setting type schemas for resolvers. Is this intuition correct?

[parthradia]

Ah, after playing with permission queries it seems this does not help you lock down access to the CRUD API. It only helps prevent mutations and reads.

Gateway it is then!

Thanks for the pointers @kbrandwijk.

[kbrandwijk]

The graphql-transform-schema library is useful with schema stitching to remove queries and mutations from your schema, or make other changes to the schema. See https://github.com/graphcool/framework/blob/master/examples/typescript-gateway-custom-schema/gateway/index.ts#L56-L61 for an example of how it's done.

[bionicles]

Hi, weighted edges and hyperedges are a critical feature of graphs and I want to help make this happen with graphQL