.Net Foundation On .NET, 16 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GraphQL Schema stitching

Description

With Schema stitching, developers can create a unified GraphQL schema from multiple underlying GraphQL APIs. This gives us the benefit of reducing multiple data queries for our data in a single request from one schema.

In this episode, Jeremy chats with the author of Hot Chocolate, Michael Staib, about how .NET developers can implement GraphQL schema stitching with Hot Chocolate.

[01:57] - What is schema stitching about?
[06:00] - Schema stitching with Hot Chocolate
[09:08] - Querying with Banana Cake Pop
[10:16] - Setting up the GraphQL Gateway
[13:56] - Customizing the schema
[20:42] - Merging related schemas

Schema Stitching Examples
https://github.com/ChilliCream/hotchocolate-examples/tree/master/misc/Stitching

Getting started with GraphQL and HotChocolate
https://channel9.msdn.com/Shows/On-NET/Getting-started-with-HotChocolate

Create web APIs with ASP.NET Core
https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-5.0

A

On.Net we are going to be talking about schema stitching. This is a feature in graphql that allows you to take separate sources and expose them as if it's just a single graph, you don't want to miss this episode with michael from chili cream.

A

Hello and welcome to another episode of on.net, I'm your host jeremy likness and today I have with me, michael from chili cream who's going to talk to us about schema stitching using graphql michael welcome to the show hi jeremy, I'm happy to be back.

A

We're excited to have you here, tell us a little bit about what you do first off and then, let's dive into schema, stitching.

B

Yeah, I'm a microsoft mvp and I'm also one of the authors of the hot chocolate graphql project for net, and we are basically building a lot of graphql tooling for the net ecosystem.

A

And that's something that I think the ecosystem it really is looking forward to graphql has become incredibly popular, and one of the things I keep hearing is that the offering on the dotnet side isn't to par with other ecosystems. So we're excited to see projects like this come in and sort of fill those gaps.

B

Yeah- and uh I think that is that has really changed now- the hot chocolate server 11 is one of the most feature-rich uh graphql servers that are out there. So we are even ahead of servers like the apollo server. We already support most of the draft features of the next graphql specs, so um we are pretty filled up together. It gaps already.

A

Well, that's exciting, why don't you show us uh some of what you've got built into this library, especially schema stitching I've. It's a phrase, that's new to me. So I'm curious what it means and and how it's implemented with your library.

B

Yeah there there are actually two terms out there in the graphql ecosystem, they're schema stitching and there is um apollo federations. So um they are so specific terms because originally apollo had a product uh which uh it was called um apollo, schema stitching and then they scrapped that and created something new called apollo federation.

B

So hot chocolate schema stitching is much more versatile than apollo federations and has actually nothing to do with their definition of federation or schema stitching. But let's just head into the topic and then you will discover what it actually is about.

B

So there are a lot of scenarios where you grow a large schema, and then there might be the point where you think about okay, I'm building here a pretty big monolith and I want to maybe chop it into multiple domain services.

B

I'm not using the the term microservice here, because we are actually more concerned about putting similar objects into a similar into separate services um and schema stitching is not only about graphql servers chopping up a graphql server into multiple, but you could also stitch in other things like odata or rest or other sources so like. If you wanted to build a nice graphql server and, for instance, use the microsoft graph, which is auditor, you could stitch that in and basically merge out of it. Your own schema, but.

A

Yeah, oh no, I was just saying that's interesting, so basically you can take different types of sources and whether it's a rest endpoint and a data endpoint, maybe multiple graphql servers and you're, pulling them together and exposing them so that as a consumer, I'm basically dealing with one source. Is that.

B

That's that's correct and that's.

A

B

Often, when you are looking at how um graphql servers are set up in node they're, most often just a facade for their for microsoft, setup for multiple rest services, or something like that, but actually facebook conceived graphql as a thin layer over their native business logic.

B

um But graphql is a great gateway like a great model which, with which you can interact and hide all those business details that you actually have multiple services. So let's um have a look at this example here.

B

So basically, what schema stitching does is we have one graph square gateway which is a simple graphql server, and then we have downstream services like maybe there is graphql server which uses up on a graphql or you have a hot chocolate, graphql server down there, and then maybe you have some arbitrary rest services and basically how that works is.

B

You would split up the logic into those downstream services and then the gateway knows how to rewrite incoming queries and delegate them to each of those domain services and uh the graphql or the hot chocolate gateway is very intelligent about it. We have um essentially an uh compiled execution plans which will um try to minimize the traffic to uh try to fetch from the least possible sources that that you basically could do with the incoming request.

B

Let's have a look at an example, and I basically have already running a few services here so think about um you're building a simple shop api where you spread out your logic. Maybe you have um one domain services, uh one domain service that only deals with the account.

B

So if we look into that here, we can see the standard hot chocolate, graphql server. We have just set up the graph browser services here, like a user repository and we have our query type and if we look into that service we can see it can basically fetch the user or multiple users and that's basically it about it about it.

B

If we look at the user type, it's uh just for demo purposes, a simple record and we just have in memory data, but that will suffice.

A

So using the new uh net types there with record, that's awesome.

B

Yeah I love them. I really love them, um and so how I use it. A user user type here or user record basically has a name, has a birth date and has a username. But apart from that, this service doesn't provide any more and then we have maybe an inventory service and this inventory service again. A standard graphql server has an inventory repository here and if you query it, it basically can give you inventory infos, which essentially consists of the product id and an indicator if something is in stock and it also provides another functionality.

B

So basically, you can ask how much shipping will cost a shipping estimate- and this basically is just an algorithm that then calculates from the price and the weight. Your shipping estimate makes sense, and then we have the product service and the product service just deals with our product. Details like we have um two queries here: the top five products or the top products.

B

I actually can provide um how much I want as a variable here um and I can ask for a specific product and if we look at the product, it's fairly simple, we have a product id. We have a name, we have a price and we have a weight.

B

Okay and then at last we have a review service and that is basically when the customer provides us with the review. We can query for that here we have. Maybe we can ask for reviews. We can ask for reviews by author. We can ask for reviews by product.

A

B

Okay, so these services are already running and we could just uh query them like. Let me get me rid of these tabs.

A

So this tool that you're using to quarry.

B

A

B

There's banana cake pop our graphql ide.

A

B

We have a lot of those funny names and we just can type in the graphql server. At the moment. um I just lined them up so starting with port 5051, actually graphql, and then I can see, for instance, here's my user service, which is a full graph. So I can just um query here, for instance, for the users and get the users that I need like that is a standard graphql server. So.

A

It works okay,.

B

You could reuse it for several things. Okay, and I could do that with all the others as well. So what we actually want to have is this one source of truth is one graphql schema, so the user doesn't want to be bothered with all those um tiny cut up services.

B

So what we would do is spin up a graphql gateway and the gateway is the standard, asp.net core project and um basically uses the standard server package which I'm using here sp the hot chocolate asp.net core package- and it also has a stitching engine in here.

A

B

And when we set that basically up, we go in our startup like for every graphql server and first, let me put in some constants. So we have the names of the services that we want to stitch in here. So I'm just using some constants. So we don't mess things things up, so we have account inventory products and reviews.

B

A

B

A

B

Exactly so that we don't have any typos.

A

B

The next thing we need to do is to um provide a means of how we can connect to our services, so we can provide um something called service connections which actually just adds here, um the http clients. So we are using the http client factory. Here we are assigning each of the http clients, one of these constants or names, and then we actually provide how we can connect to that. There could be logic that deals with authentication to these services.

B

So that's up to you how you configure your http client here, okay, okay, so the next thing is actually we are creating a graphql server like any other other graphql server, so we say at graphql server and now we actually need to add remote services, and we can do that by adding one of the those configuration apis that we provide, which just stay at remote schema. And then we tell them here the the name of the schema- and this aligns with our http client connection.

A

So it's going to basically use that client go out and ask for the schema from the service. Is that what.

B

That does yeah okay, okay, so let's just run that.

B

Typing in the gateway we're starting up the gate frame, all the other services are actually running. So, if you look at my console, I have all these colors and each of these tabs is actually one of those downstream services already running here.

A

B

Okay, so, instead of using 5051, we are going now to a new tab and asking for 5050, and we are getting this merged schema here.

A

B

This is just basic, auto merged and auto merged schema, which basically just exposes the data or the schemas as they were just merged together. It's actually not what we want, but anyway, let's just um just query them here, just to verify that it works and it works okay.

B

So, but what we actually want is to create the schema in a way that represents our vision of our business domain.

A

B

So for that we actually first get rid of all the of all the root types or basically, all the entry points to our um field resource, and we can do that by just telling the schema builder here to ignore the root types, and this will basically ignore the query or the mutation type. So the top level types of the graphql servers that we are stitching in okay, so now our type actually would be empty. That would be invalid. Schema.

A

So it has the metadata from the services, but it's not exposing anything for the schema, because you told it to ignore what it grabbed.

B

A

B

If it, if we would start it like that, uh the schema builder would also remove all the types that cannot be reached and we would have an empty schema.

A

B

But that is actually not what we want. We want to a little bit craft our schema here, so we are going to our account service now and we can add here a graphql file. So let's call it stitching dot graphql.

B

And then we might want to expose the currently sign in user as a field called me. Maybe so, let's add here um a type in the graphql sdn language and we are basically telling um the stitching server. We are extending the query type with the field me and the field me is delegated to the account service, so so to this service.

B

You can actually omit this field, but just to make it more transparent, and then we basically and all having here this stitching pass, which lets us navigate to the exact data. So I'm delegating it to the user field that I exposed on my query type here and I could, for instance, here just um add a constant one. Actually, I could also pick some data from my context, which is aggregated in the gateway, like the user token, from the user token claims and put that in.

A

B

But, let's just for the demo, stick with this constant here: okay, okay! So there are multiple ways to get this file. I could expose it again on my graphql server through the graphql schema, or I could fetch it via a simple http call or in our instance, let's just prep this file from a file here and use it like that.

B

So what I'm doing now is just telling the um schema builder here to grab that file from.

B

B

um Grabbing grabbing it from the accounts directory and using that to stitch that in and since we have use no query type here, we are also adding um an empty query type so that we can merge it with the extensions that we are adding. So we are saying add that from string and we are adding a empty query type, that's for good measure. We could also do that everything here with code first by the way, so I could create a simple sc, sharp class that is empty, but in this case just writing.

B

This simple sdl here is a bit simpler.

B

Okay, let's just restart that, and we check what happens.

A

B

So if we go back to our schema, we can just re-fetch that, and we already can see this is wrong. It's it doesn't have users anymore, but it has no me and now I can actually go to me and get the currently signed in user.

B

So that was uh pretty simple to just get a very simple stitch in here.

A

B

So, but that is actually not so so really cool, so let's uh really go through another few integrations and then see how we really can transform this um this project.

B

So the next thing that we want to have is to essentially expose the top products of our schema, and for that we go into products and add a new file again stitching, dot rough ground, and we basically ask for the top products and again we just extend the query type and delegate that to um one of our uh one of our fields and this time I'm not specifying the pass, because it's the same so it aligns in this in this instance.

B

So I just can't say, delegate to schema products and then everything is done for me automatically. So again, let's put that in the in the schema builder- and in this case I can just say, products.

B

And it's very fine that everything.

B

Works and we have the top products in here- okay,.

B

So now I can essentially ask for the products and now really the thing will open up for us, because now we can actually put the things together. In this instance, I actually have specified that there is a field first.

A

First, five products.

B

Yeah so that I have to provide here so um in this instance, I then have to provide it.

A

B

Okay, so let's really merge these data together. We just have a very simple schema now with two fields, but they aren't really integrated like I have this inventory data, and ideally I want to have that on my products.

B

So, let's add here a new file, stitching, dot graph.

B

B

And, for instance, adds the in-stock information.

A

B

This I extend now the product type from a different service that I just don't know, but I know that it exists, but I'm saying I'm just extending this type from the different service and I now need maybe information from that service to really to really stitch that together and for that. I actually um use this path here. To say: okay, delegate to this inventory info, the inventory info use the field upc from the other servers and then uh really dig into on and only take the is in stock field and.

A

B

To the in stock field, so we are also rewriting here names and really is doing a deep stitch. Sorry.

A

B

Okay, so the next thing is that we are also grabbing here some fields from the from the other service. Again, we want, in this instance the price field and the weight, and we want to call shipping estimate and then get back. The shipping estimate, okay, let's just wire- that up.

B

And I'll start up here.

B

B

Do one more thing and then we can restart it.

A

B

Have a look at our schema, how it worked out, so the next thing is that we want to want to integrate reviews.

B

So then, again, we just provide another stitching graph by the way they they because you specify which stitching or which graphical file you want. Here. um You can name it. However, you want I'm just doing and naming it stitching for this demo and also, as I said, you can expose them via htp or integrate them in to your domain service. Graphql schema okay, so here we really want to have. We have the reviews and we want to um stitch these reviews into the user and the products.

B

So we accept essentially extending the user here and delegating or stitching the data from the reviews by author field into the user and again we are needing some. We need some input data from the other service, so we specify that we need the field from this user type and we need the id.

A

B

Okay, the next thing is, we want to stitch that into the uh into the um also yes, exactly and it's the same uh setup. We again grab some fields from the product stitch it in and now our our field, our service, becomes more complete. We just have uh one thing, maybe left.

B

We might also want on the review the products, so we can go back to our product service and then at the product reviews here so basically in this instance a wrong snippet. Sorry for that, the review product. So basically we are doing the reverse. We are putting the product on the reviews and also last but not least, we are putting the review on the author.

A

Okay, so we went both ways. I can look at a user and see their reviews or I can look at a product see the reviews or I can look at reviews, see the associated product.

B

Exactly and the cool thing here is that these services are now independent, they have no hard dependencies, so you could have various teams working on these products independently and deploying them independently, and the stitching server can then hot reload its schema and then basically stitch these things in so for.

A

B

Let's, um let's just check that I put in all the.

B

The extension files- no, I was one missing here, so we are missing the um reviews. Let's just add, let's just add that.

B

On our server and have a look at our new schema.

B

Let's see if that works out, yes, it.

A

B

And now, let's explore, we again have just one field, but we can see like do you remember we stitched in the reviews in the user. We can see the reviews from this user. You could go then in we can see that we now have the product here and also the user. So we could go back to the user in this case or go for the products and then from the products. We again could get all the reviews of the product and then the user makes sense again.

B

So you can see you can dig really into a graph. We have now a proper graph and can do a lot of nice queries now.

A

B

Let's try that out a bit: oh yeah grabbing the reviews- maybe just the body- and this in this instance yeah. So the user had two reviews here, we're getting them, but now we also can add, for the can go for the product, maybe for the product reviews and then have a look at all the authors that are there and that broke that road reviews and again for the body. You could execute that and see that the data is there.

A

B

And we can see that it's really fast still. It has not so much overhead, since we are looking at the stitches that you do. Basically, as you extends, and we are optimizing to fetch the data so there's more possible, which I don't fit in this demo, just as the hinge, so you can look for it in the documentation or go to our slack channel and ask us there so there's possible to provide like data that one service provides or the other like, for instance, maybe the review service actually also provides the username.

B

Maybe we also have here author data that has the username actually that originally comes from account like here, but if you just ask for the username and for the reviews, we could then optimize uh the um request to the downstream services that you just asked one service, so that is also possible and also what we are bringing in our january release is also that you can use graphql over grpc to have a a faster channel to the downstream services.

B

A

So I like what you said: this isn't microservice aggregation. If you will it's more creating the domain model that you want, the correct object graph and exposing it in a way that the consumer doesn't have to worry about where the service lives or what it is they talk to one gateway, they get a graph of information and that information may come from multiple places, but you've just shown how easy it is to configure it to aggregate and stitch the schema. I guess.

B

Yeah exactly, and that gives you flexibility in how you split it up across teams or depending to your structure, that you want to show.

A

Awesome, thank you. So much that's an exciting feature. I look forward to getting feedback and and comments I'm interested if people have used this feature so be sure to use the comments section and give us your thoughts and feedback. Thank you. This has been another episode of.

A

A