Schema Orchestration

[michaelstaib]

Goals for Version 12:

Schema stitching should be configurable

Our view here is that we want to be able to configure the external schema through an easy to use UI. There should be no need to code. Schemas should be created from their micro-service via simple drag&drop and deployed by clicking a publish button.

Stitching does not mean GraphQL only

We not only want to stitch together GraphQL schemas. We want to be able to consume gRPC, Swagger (REST) and OData as schema sources. They should be treated as if they were GraphQL schemas.

Stitching does not just mean merging two schemas

We think in schema representations. We want to be able to have representations of our data without the need of reshaping our micro-services. The GraphQL sub-services or micro-services should be clean and without considerations of the overall schema. The gateway should be able to completely rewrite how a schema is represented. So, there could be cases where the representation of the inner schemas is completely different to the external representation.

Everything is just GraphQL

You can express your gateway completely with a GraphQL file just like today.

Monitoring

The schema registry will keep track on performance data off all the orchestrated services and will have notification mechanisms so that it is easy to keep track of the health status of the system.

CI/CD

We want to have a change preview API. This basically means that you can push a schema to the schema registry from your build and the schema registry will give you a report that tells you which changes are breaking. This helps you avoid breaking your public apis and build powerful CI/CD pipelines.

Resilience

The gateway will not go down when one server is down. GraphQL is great since it allows to provide errors on resolver basis, this mean that if one server is down not the the whole system is down.

Aliases and Conversions

When configuring a schema, we will have tooling available so that you can merge scalars from different server platforms. Also, you will be able through the UI to add small functions that normalize the scalar output. For instance, a DateTime scalar will not always mean the same thing on every platform, with Hot Chocolate schema orchestration, you will be able to normalize the values and we will apply these converters to your schema data. This makes the external schema predictable and homogenous.

Configuring a gateway should be dead simple.

[michaelstaib]

With version 9.1 we will add the first big block for that with our execution plans.

With that we will divert away from the default GraphQL execution algorithms and will have an optimized execution algorithm per query.

Ordered Execution
Stitching Execution Plans

We still will be 100% spec compliant:

... and hence the server has the freedom to execute the field entries in whatever order it deems optimal.

The spec defines default algorithms but the servers are free to optimize the algorithms.

So, far as I know only GraphQL-Java and HC are exploring this at the moment.

What does that mean exactly?

Each query execution will become a pipeline of tasks that describes how the query data is resolved. Execution plans will be saved locally or with the schema registry. There will be automatic execution plan tuning available.

When we expose our resolvers like the following the execution engine will be able to optimize on the available data:

public Task<Persion> GetPerson([DataLoader("personById")]IPersonDataLoader dataLoader, string personId) 
{
   // ...
}

Resolvers like the above tell the execution engine what they use argument wise and services wise, this will let the execution engine customize the execution behavior and in this case bundle all personById DataLoader together. But there are other things like, do I need data from my parent object?

public Task<string> GetPersonName([Parent]Person person) 
{
   // ...
}

The above resolver for instance needs the whole source object from the parent resolver and hence has to be executed after the parent resolver. But if the name could be resolved with the same arguments like the parent resolver needs then although a resolver might be a child resolver it could be executed in parallel.

There are more scenarios here and I will write more on how that works in the sub issues once we are further along with this.

[michaelstaib]

Subscription Stitching

[michaelstaib]

Also, what we want to do with version 10 is introducing a new more efficient server to server protocol. So, we will support the standard protocols but we also will have an optimized GraphQL protocol between HC servers that we will make available as spec for others.

[OneCyrus]

while i really like your ideas about the tooling there's one concern with where the stitching rules are stored. while your proposal with the drag&drop UI sounds nice and easy to use, I'm not sure that this should be the primary way to keep the stitched schema up to date.

Schema stitching should be configurable

Our view here is that we want to be able to configure the external schema through an easy to use UI. There should be no need to code. Schemas should be created from their micro-service via simple drag&drop and deployed by clicking a publish button.

my main concern with this is that any project of a larger size is working on multiple microservices at any time. to keep the CI/CD of those microservices in sync with the required changes on the central schema stitching is getting very hard very soon. you basically need to have two changes (the graphql-schema in the microservice and the logic how this should be stitched in the schema registry) coordinated.

what about if we could define these rules in the same code where we have the (microservice-) schema? we could have CI/CD pipelines which could check for consistency. there's no coordination needed for releases. we have a single source of truth and basically inversion of control for schemas.

[michaelstaib]

What do we do with things where you want multiple schema representations? Then you would need to redeploy all the micro services in order to get a new schema representation in.

This is one of my main concerns. Also I think why should the micro service be bothered with logic about the bigger picture? And this becomes an even bigger question when you take OData and rest into account. How does a legacy rest service tell the gateway its structure.

That does not mean I am completely opposed to your Idea here, I mean that is what Apollo federation does.

There must be a better solution out there. I mean we have two more month to figure out how this is going to work :) Then I would like to start implementing this one.

[OneCyrus]

yes, there's not one way which solves all problems. i guess there are two competing solutions which fundamentally define how a company is organized.

for things like REST you can't annotate somwhere else than a central place (or you are required to have some kind of proxy microservice just for this, which is not great as well). So REST can only be stitched at registry level.

for multiple schemas/representations. i see there could be some use cases here. but for our company this is one of the design goals to prevent from happening. we come from multiple representations (REST) which wasn't that great. now with graphql we have the possibility to just have one graph which spans the whole company. using different graphql schemas would put as back to the REST days where we have to optimize for different representations which makes the developement a lot more complex.

but yes it's hard and that's probably why apollo is still changing directions as there is no obvious solution. i guess it all comes down to organization/processes rather than technology.