Name: GraphQL。走向一種通用的查詢語言，由Michael Mifsud撰寫｜JSConf EU 2019。 (GraphQL: Towards a universal query language by Michael Mifsud | JSConf EU 2019)
Uploaded: 2021-01-14T10:25:10.000Z
Duration: 27 min 13 s
Description: 【看影片學英語】數萬部 YouTube 影片，搭配英漢字典即點即查，輕鬆掌握單字發音與用法，長久累積看電影不必再看字幕。

You might have heard of it by now, and, if you have, you've heard about how to it's great

for performance, backwards compatibility, and great for those hard to get out stains!

How can GraphQL have these supposed superpowers?

I think the key to this lays in its basic building blocks.

In this talk, we will start off by taking a look at the schema definition language,

RSL, and the resolvers, and understand how they work together to execute a query.

Then I will show ways to use these features to graph all the things before finally entering

the "don't try this at home" portion of the talk.

We work on building tooling services and platforms to enable at Red Bubble.

I'm the maintainer of Lis Sass and notes Sass.

Everything else builds on top of or happens because of the schema.

It is defined using the schema definition language.

Our conference type is a name field which we set as a string.

String is one of the skeletypes, in graph, and others like ints, floats, and booleans

We have a speakers' field which has an array of the speaker type.

It's not a built-in type, so we define it ourselves.

Our speaker has a name and a favourite emoji.

This gives me licence to use member throughout the talk!

We have some fields with exclamation marks and others don't.

It means a field is omitted but still valid.

IDs are convenient for querying and mutating data.

Speaking of querying and mutating data, we have the query types called root types.

There are others too but we're not going to talk about them today.

On our query type, we have a conference field that returns any conferences we know about.

We also have a speaker's field that has a required emoji argument and returns some speakers.

It has a speak field, that takes a speaker ID and a Conference ID.

Something to note, it's common to refer to fields on query mutation types.

You see return-type mutation looks like the return type of a query field.

A field on a mutation could return things like booleans but as richer types as part

There is some detail as to how these are defined that we won't go into today.

The important thing to take away from this is the field in the query type to ask for

information whereas fields and mutation type typically change things.

Lastly, the resulting data from mutation can be expected to have the changes already applied.

The schemas are the skeletons of GraphQL and at their beating heart.

With the amazing things that GraphQL can do, you would think they would be pretty complicated,

but it's the simplicity of resolvers that is the key to their flexibility.

We're going to talk about these three today, but there are others.

You can define a resolver or any or all fields on your schema, including fields in the query

type, the speak field, and fields on any type like the emoji field on the speaker type.

Inside a resolver, you can do anything it could do in any other JavaScript function.

The only requirement is that it returns of value in the shape that matches the type of

It has a query object representing the query type.

And a query object, there is a speaker's resolver.

We can access that argument by the name on the arc's argument on its resolver.

We know from our schema that the query should returning the or an array of speaker types.

Here it's returning an array of objects which have an integer ID field and a name and an

emoji string field which means they match the expected shape of the query and all is

Remember, the conference field doesn't have an exclamation mark so it's entirely optional

Our speaker mutation - here we have a speaker mutation loading data from the context by

It makes it useful for storing things like configuration or services like database connections.

After it is loaded, the speaker ID argument is appended to the conference object, the

- finally does a query for the conferences that the speaker is attending.

But it is just a groundwork for what is coming up next.

We're going to take a look at practical use of resolvers to feel how they work together

The simplest resolver is one that returns an object.

Earlier, we saw a resolver and all good because it returned a resolver that matched the shape

of the speaker type before how does GraphQL match the speaker shape?

Is there some kind of internal validation engine or some form of intro expect on their

No doubt there is a way to return these types.

If you're like me, you're thinking about how you would have done it yourself.

Every field from GraphQL gets a default resolver.

For any field, it takes the object, the parent object and tries to be the access a field

as a function call, or an object property on the parent.

Importantly, this happens recursively, so, if a field returns a type, the field's return

type is a custom type, then all the fields on that type have their resolvers called.

The schema for our speaker's query returns return type to a null or an array of speaker

字幕列表影片播放

GraphQL。走向一種通用的查詢語言，由Michael Mifsud撰寫｜JSConf EU 2019。 (GraphQL: Towards a universal query language by Michael Mifsud | JSConf EU 2019)

scenario

context

applause

expect