search

valueflows / vf-graphql

vf-graphql has moved to https://lab.allmende.io/valueflows/vf-graphql
Other
22 stars 3 forks source link

Further schema modularisation #61

Closed pospi closed 4 years ago

pospi commented 4 years ago

It would be worth decomposing what's been done into module-specific "plugins" as the HoloREA network boundaries solidify.

To start with, let's at least break things out into specification / observation / planning / recipe?

This looks like it does what we need: https://github.com/Urigo/merge-graphql-schemas

almereyda commented 4 years ago

How can further schema modularisation be thought as a special case of GraphQL federation as suggested in https://github.com/valueflows/vf-ui/issues/1?

pospi commented 4 years ago

I'm not sure it can... I think those are separate problems, unless you have insights I don't (I have only really done a surface-level investigation of this).

Federation = runtime combination of multiple schemas pointing at different backend services into a single query API.

Modularisation = compile-time combination of multiple fragments of the same schema which correspond to separate featuresets within the same system.

So federation is like, I have 2 servers that both carry observation data and I want to easily query both without having to think about where the data lives. Modularisation is like, my system only wants to implement observation and specification services but wants to omit planning, so it shouldn't be advertising to anyone that it supports the queries & mutations related to planning.

pospi commented 4 years ago

Done with the core functionality needed for this, see updated readme for the new dynamic schema API.

pospi commented 4 years ago

Ah! I meant to loop back and ping you on this @almereyda but dropped the ball on that... I was curious what you thought of these latest additions.

My schema building function basically does a merge on several schemas to generate a single flattened schema for whatever modules a specific implementation provides... you can see this in action in Holo-REA. The "bridging" schemas are injected automatically, and include the parts of the schema that connect different paired modules.

Looking at this now it feels a lot like something that is faking federation via some bespoke logic. I'm curious for one if federation is flexible enough to do such bridging, or if the mechanisms are simpler and don't provide for more complex bindings as in observation <> planning.

We might also have a requirement for weird things like "substituteable modules"- the work @ivanminutillo is working on will have separate agent modules that are external to the rest of the API, so we're thinking about having an externalAgent which would assign string values instead of the Agent type to fields like EconomicEvent.provider. But those may actually be incompatible schemas then, and the appropriate option could be to wrap these external services in a Agent GraphQL resolvers instead.

My interpretation has also been that federation isn't quite ready for widespread support (especially in the frontend... most of Apollo's tooling seems to be for Express). Curious to have that presumption checked as well...