Name: 分散グラフの構築 w/ アポロフェデレーション - Gerwin Brunner & David Krehling - JSConf US 2019 (Building a distributed graph w/ Apollo Federation - Gerwin Brunner & David Krehling - JSConf US 2019)
Uploaded: 2021-01-14T10:23:01.000Z
Duration: 28 min 21 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

Building A Distributed Graph With Apollo Federation - Gerwin Brunner

過去形

All right, so now we have two speakers coming onstage, Gerwin Brunner and David Krehling

Let's give them a warm welcome [applause]

Gerwin: Yeah, I know what they meant before.

Today we're going to talk about building a distributed graph with Apollo Federation and

maybe before we dive in, some questions for you just so we get to know you a little bit

And how many of you have heard of the Apollo Federation.

But that's good, because that is why we're here.

This guy next to me is Gerwin Brunner, we're both from Vienna Austria, and we work there

in one of the biggest banks in Austria and central Eastern Europe region and we're building

a state of the art web application replacing an old legacy one and we tried to incorporate

GraphQL like from day one into our design so we got quite a few learnings and basically

So I guess most of you know REST, and I guess most of you know like the issues you get with

REST, especially when you get like -- when you have like more complex or bigger applications

You have several issues, for example, if you need data from different kinds of services,

you always have to call them separately, you have to get all the data from them.

And basically this leads to a slow network environment and you basically get data you

GraphQL is trying to solve that by putting a data graph in between which is described

in this so-called schema and that basically allows you to query several services at once

and to query exactly for the data you really need.

What's also cool, just like a side fact, you can also put GraphQL as a layer on top of

your REST services so if you can't switch like this, you can really build the REST service

into your GraphQL environment and then replace it piece by piece.

So like I said before, like one of the core building blocks of GraphQL is the schema.

Which is shared between the client and server, and basically it's there to validate all the

inputs or the payloads you define in the schema.

So every time you make a request and GraphQL terminal, it would be a query or a mutation,

the schema checks if one the types are proper and if they are input or the payload is complete,

and if there's -- if the data is in there or the data that you want.

Another thing is that it's like strictly typed, so you also have type validation in there,

The second big building block is the resolver, and basically in the resolver, not all of

the metric, but basically all the metric happens because it's there to process data, and to

So every time he query something for example, it goes through the resolver and basically

that's the point where you connect to the database, where you connect to APIs, to other

So maybe like the people that already worked with GraphQL know that issue, that like when

it gets a little bit more complex and as it gets a little bit bigger, you create this

huge monolithic schema, which basically creates a mess.

One would be to use schema stitching, which basically creates a mess, as well.

Because like one of the biggest down sides is if you try to separate the schema which

shouldn't be separated, you create like lots of overhead code, you create lots of effort,

lots of work, the bigger it gets, the more you separate t the harder it gets to maintain.

Even to understand and basically at some point it's impossible to test it.

The smart guys there, and they created Apollo Federation.

What they tried to do is incorporate some core principles, basically the first one it

should be a declarative, meaning no schema stitching at all, so you're freed of that,

and another thing which is pretty great is that you have a separation of concerns, meaning

you divide your schema into several stand-alone schemas, which then can be referenced to each

And basically to bring all of that back together to the client, Apollo created the gateway

which takes all those several federated schemas, and makes like one huge schema out of it again,

so basically like the client, nothing changed at all, it's only on the server side.

So to build up federated schema, you have several building blocks, we go through this

So basically an entity is just -- is just a GraphQL type basically the only thing that's

changed is this @key directive on the right-hand side of the customer.

Which basically creates a connection between the several schemas, so by adding this @key

field, you create this connection point and basically what it is is nothing else than

as a primary key, basically it works like an SQL.

So as soon as you created this entity, which again is basically just an @key directive,

you can reference it from different schemas or services, so maybe to go back, just imagine

this code example, for example, would be in a schema in the customer service, and the

next one here would be, for example, in the order service.

So basically everything you do there is just creating the same type again, but putting

分散グラフの構築 w/ アポロフェデレーション - Gerwin Brunner & David Krehling - JSConf US 2019 (Building a distributed graph w/ Apollo Federation - Gerwin Brunner & David Krehling - JSConf US 2019)

字幕リスト動画再生

分散グラフの構築 w/ アポロフェデレーション - Gerwin Brunner & David Krehling - JSConf US 2019 (Building a distributed graph w/ Apollo Federation - Gerwin Brunner & David Krehling - JSConf US 2019)

stuff

basically

native

applause