Last Sync: 2022-11-19 17:00:05
This commit is contained in:
parent
90e6010742
commit
af7caca54b
6 changed files with 60 additions and 12 deletions
|
@ -2,7 +2,7 @@
|
||||||
title: Apollo Client
|
title: Apollo Client
|
||||||
categories:
|
categories:
|
||||||
- Databases
|
- Databases
|
||||||
tags: [graph-ql, apollo]
|
tags: [graphql]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Apollo Client
|
# Apollo Client
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
title: Apollo Server
|
title: Apollo Server
|
||||||
categories:
|
categories:
|
||||||
- Databases
|
- Databases
|
||||||
tags: [graph-ql, apollo]
|
tags: [graphql]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Apollo Server
|
# Apollo Server
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
title: Using arguments with Apollo Client
|
title: Using arguments with Apollo Client
|
||||||
categories:
|
categories:
|
||||||
- Databases
|
- Databases
|
||||||
tags: [graph-ql, apollo]
|
tags: [graphql]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Using arguments with Apollo Client
|
# Using arguments with Apollo Client
|
||||||
|
@ -114,7 +114,7 @@ const resolvers = {
|
||||||
|
|
||||||
With the server changes complete, we can now issue a query with an argument from the client:
|
With the server changes complete, we can now issue a query with an argument from the client:
|
||||||
|
|
||||||
```gql
|
```js
|
||||||
query track(id: 'xyz'){
|
query track(id: 'xyz'){
|
||||||
title
|
title
|
||||||
}
|
}
|
||||||
|
@ -126,7 +126,7 @@ This will return the `title` field from the track with the specific id. This que
|
||||||
|
|
||||||
What about the following query:
|
What about the following query:
|
||||||
|
|
||||||
```gql
|
```js
|
||||||
query track(id: 'xyz'){
|
query track(id: 'xyz'){
|
||||||
title
|
title
|
||||||
author {
|
author {
|
||||||
|
@ -137,7 +137,7 @@ query track(id: 'xyz'){
|
||||||
|
|
||||||
It's not obvious how the resolver should respond to the nested query here since author name is not a field on `Track`, it is a field on `Author`:
|
It's not obvious how the resolver should respond to the nested query here since author name is not a field on `Track`, it is a field on `Author`:
|
||||||
|
|
||||||
```gql
|
```js
|
||||||
type Track {
|
type Track {
|
||||||
id: ID!
|
id: ID!
|
||||||
title: String!
|
title: String!
|
||||||
|
@ -159,7 +159,7 @@ type Author {
|
||||||
|
|
||||||
This is where we use a **resolver chain**. Because `authorId` exists on `Track` we can use this to get the `name` part of the query. We already have a resolver for `author` under the `Track` resolver:
|
This is where we use a **resolver chain**. Because `authorId` exists on `Track` we can use this to get the `name` part of the query. We already have a resolver for `author` under the `Track` resolver:
|
||||||
|
|
||||||
```gql
|
```js
|
||||||
Track: {
|
Track: {
|
||||||
author: ({ authorId }, _, { dataSources }) => {
|
author: ({ authorId }, _, { dataSources }) => {
|
||||||
return dataSources.trackApi.getAuthor(authorId);
|
return dataSources.trackApi.getAuthor(authorId);
|
||||||
|
@ -167,8 +167,56 @@ Track: {
|
||||||
},
|
},
|
||||||
```
|
```
|
||||||
|
|
||||||
Notice that `authorId` is used in the place of the `parent` parameter. It already exists on the `Track` that we return from the query. So this can be invoked to fulfill `author` and thereby access the author name from the `graph`.
|
Notice that `authorId` is used in the place of the `parent` parameter. It already exists on the `Track` type that wraps. So this can be invoked to fulfill `author` and thereby access the author name from the graph.
|
||||||
|
|
||||||
> I don't really understand this but the general point seems to be that the resolvers outside of the main `Query` block in the resolver are tied to a data type and can be used to magically populate query requests for nested fields providing a key is on the main datatype returned.
|
> I don't really understand this but the general point seems to be that the resolvers outside of the main `Query` block in the resolver are tied to a data type and can be used to magically populate query requests for nested fields providing a key is on the main datatype returned.
|
||||||
|
|
||||||
Now repeat this example with `modules`
|
Now repeat this example with `modules`
|
||||||
|
|
||||||
|
This process is also required for our extended schema. The `Track` type now has a `modules` field that comprises an array of the `Module` type.
|
||||||
|
|
||||||
|
Here's a reminder of the `Module` type:
|
||||||
|
|
||||||
|
```js
|
||||||
|
type Module {
|
||||||
|
id: ID!
|
||||||
|
title: String!
|
||||||
|
length: Int
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The modules for a `Track` can be sourced from the track `id`. So we can again add a resolver chain function to the resolvers file:
|
||||||
|
|
||||||
|
```js
|
||||||
|
const resolvers = {
|
||||||
|
Query: {
|
||||||
|
tracksForHome: (_, __, { dataSources }) => {
|
||||||
|
return dataSources.trackApi.getTracksForHome();
|
||||||
|
},
|
||||||
|
track: (_, { id }, { dataSources }) => {
|
||||||
|
return dataSources.trackAPI.getTrack(id);
|
||||||
|
},
|
||||||
|
},
|
||||||
|
Track: {
|
||||||
|
author: ({ authorId }, _, { dataSources }) => {
|
||||||
|
return dataSources.trackApi.getAuthor(authorId);
|
||||||
|
},
|
||||||
|
modules: ({ id }, _, { dataSources }) => {
|
||||||
|
return dataSources.trackAPI.getTrackModules(id);
|
||||||
|
},
|
||||||
|
},
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
Once again we are using a property on the parent `Track` type to use as a parameter in the resolver function.
|
||||||
|
|
||||||
|
This setup would enables like the following to be run:
|
||||||
|
|
||||||
|
```js
|
||||||
|
query track(id: 'xyz'){
|
||||||
|
title
|
||||||
|
modules
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The '
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
---
|
---
|
||||||
categories:
|
categories:
|
||||||
- Databases
|
- Databases
|
||||||
tags: [graph-ql]
|
tags: [graphql]
|
||||||
---
|
---
|
||||||
|
|
||||||
# The journey of a GraphQL query
|
# The journey of a GraphQL query
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
---
|
---
|
||||||
categories:
|
categories:
|
||||||
- Databases
|
- Databases
|
||||||
tags: [graph-ql]
|
tags: [graphql]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Schema Definition Language
|
# Schema Definition Language
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
title: Using GraphQL with Node.js
|
title: Using GraphQL with Node.js
|
||||||
categories:
|
categories:
|
||||||
- Databases
|
- Databases
|
||||||
tags: [graph-ql, node-js]
|
tags: [graphql, node-js]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Using GraphQL with Node.js
|
# Using GraphQL with Node.js
|
||||||
|
|
Loading…
Add table
Reference in a new issue