You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/graphql/quick-start.md
+18-18Lines changed: 18 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,15 +12,15 @@ Start by installing the required packages:
12
12
$ npm i --save @nestjs/graphql graphql-tools graphql
13
13
```
14
14
15
-
And depending on what you use (Express or Fastify), you need to install `apollo-server-express` or `apollo-server-fastify`.
15
+
Depending on what underlying platform you use (Express or Fastify), you must also install either`apollo-server-express` or `apollo-server-fastify`.
16
16
17
17
#### Overview
18
18
19
-
Nest offers two ways of building GraphQL applications, the **schema first** and the **code first** methods.
19
+
Nest offers two ways of building GraphQL applications, the **code first** and the **schema first** methods. You should choose the one that works best for you. Most of the chapters in this GraphQL section are divided into two main parts: one you should follow if you adopt **code first**, and the other to be used if you adopt **schema first**.
20
20
21
21
In the **code first** approach, you use decorators and TypeScript classes to generate the corresponding GraphQL schema. This approach is useful if you prefer to work exclusively with TypeScript and avoid context switching between language syntaxes.
22
22
23
-
In the **schema first** approach, the source of truth is a GraphQL SDL (Schema Definition Language) SDL is a language-agnostic way to share schema files between different platforms. Nest automatically generates your TypeScript definitions based on the GraphQL schemas (using either classes or interfaces) to reduce redundancy.
23
+
In the **schema first** approach, the source of truth is GraphQL SDL (Schema Definition Language) files. SDL is a language-agnostic way to share schema files between different platforms. Nest automatically generates your TypeScript definitions (using either classes or interfaces) based on the GraphQL schemas to reduce the need to write redundant boilerplate code.
24
24
25
25
#### Getting started with GraphQL & TypeScript
26
26
@@ -36,7 +36,7 @@ import { GraphQLModule } from '@nestjs/graphql';
36
36
GraphQLModule.forRoot({}),
37
37
],
38
38
})
39
-
exportclassApplicationModule {}
39
+
exportclassAppModule {}
40
40
```
41
41
42
42
The `forRoot()` method takes an options object as an argument. These options are passed through to the underlying Apollo instance (read more about available settings [here](https://www.apollographql.com/docs/apollo-server/v2/api/apollo-server.html#constructor-options-lt-ApolloServer-gt)). For example, if you want to disable the `playground` and turn off `debug` mode, pass the following options:
@@ -54,16 +54,18 @@ import { GraphQLModule } from '@nestjs/graphql';
54
54
}),
55
55
],
56
56
})
57
-
exportclassApplicationModule {}
57
+
exportclassAppModule {}
58
58
```
59
59
60
60
As mentioned, these options will be forwarded to the `ApolloServer` constructor.
61
61
62
62
<app-banner-enterprise></app-banner-enterprise>
63
63
64
-
#### Playground
64
+
#### GraphQL playground
65
65
66
-
The playground is a graphical, interactive, in-browser GraphQL IDE, available by default on the same URL as the GraphQL server itself. With your application running in the background, open your web browser and navigate to `http://localhost:3000/graphql` (host and port may vary depending on your configuration). You should see the GraphQL playground, as shown below.
66
+
The playground is a graphical, interactive, in-browser GraphQL IDE, available by default on the same URL as the GraphQL server itself. To access the playground, you need a basic GraphQL server configured and running. To see it now, you can install and build the [working example here](https://github.com/nestjs/nest/tree/master/sample/23-graphql-code-first). Alternatively, if you're following along with these code samples, once you've complete the steps in the [Resolvers chapter](/graphql/resolvers-map), you can access the playground.
67
+
68
+
With that in place, and with your application running in the background, you can then open your web browser and navigate to `http://localhost:3000/graphql` (host and port may vary depending on your configuration). You will then see the GraphQL playground, as shown below.
67
69
68
70
<figure>
69
71
<imgsrc="/assets/playground.png"alt="" />
@@ -83,11 +85,11 @@ GraphQLModule.forRoot({
83
85
84
86
In the **code first** approach, you use decorators and TypeScript classes to generate the corresponding GraphQL schema.
85
87
86
-
To use the code first approach, start by adding the `autoSchemaFile` property to the options object.
88
+
To use the code first approach, start by adding the `autoSchemaFile` property to the options object:
A fully working sample is available [here](https://github.com/nestjs/nest/tree/master/sample/23-graphql-code-first).
104
+
A fully working code first sample is available [here](https://github.com/nestjs/nest/tree/master/sample/23-graphql-code-first).
103
105
104
106
#### Schema first
105
107
106
-
To use the schema first approach, start by adding a `typePaths` property to the options object.
108
+
To use the schema first approach, start by adding a `typePaths` property to the options object. The `typePaths` property indicates where the `GraphQLModule` should look for GraphQL SDL schema definition files you'll be writing. These files will be combined in memory; this allows you to split your schemas into several files and locate them near their resolvers.
107
109
108
110
```typescript
109
111
GraphQLModule.forRoot({
110
112
typePaths: ['./**/*.graphql'],
111
113
}),
112
114
```
113
115
114
-
The `typePaths` property indicates where the `GraphQLModule` should look for GraphQL files. These files will be combined in memory; this allows you to split your schemas into several files and locate them near their resolvers.
115
-
116
-
Creating GraphQL types and corresponding TypeScript definitions is redundant and tedious. It leaves us without a single source of truth -- each change made within SDL forces us to adjust interfaces as well. To address this, the `@nestjs/graphql` package can automatically generate TS definitions from the abstract syntax tree (AST). To enable this feature, add the `definitions` options property when configuring the `GraphQLModule`.
116
+
You will typically also need to have TypeScript definitions (classes and interfaces) that correspond to the GraphQL SDL types. Creating the corresponding TypeScript definitions by hand is redundant and tedious. It leaves us without a single source of truth -- each change made within SDL forces us to adjust TypeScript definitions as well. To address this, the `@nestjs/graphql` package can **automatically generate** TypeScript definitions from the abstract syntax tree ([AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree)). To enable this feature, add the `definitions` options property when configuring the `GraphQLModule`.
117
117
118
118
```typescript
119
119
GraphQLModule.forRoot({
@@ -124,7 +124,7 @@ GraphQLModule.forRoot({
124
124
}),
125
125
```
126
126
127
-
The path property of the `definitions` object (e.g., `src/graphql.ts` above) indicates where to save TypeScript output. By default, all types are generated as interfaces. To generate classes instead, specify the `outputAs` property with a value of `'class'`.
127
+
The path property of the `definitions` object indicates where to save generated TypeScript output. By default, all generated TypeScript types are created as interfaces. To generate classes instead, specify the `outputAs` property with a value of `'class'`.
128
128
129
129
```typescript
130
130
GraphQLModule.forRoot({
@@ -136,7 +136,7 @@ GraphQLModule.forRoot({
136
136
}),
137
137
```
138
138
139
-
The above approach dynamically generates type definitions each time the application starts. Alternatively, it may be preferable to build a simple script to generate these on demand. For example, assume we create the following script as `generate-typings.ts`:
139
+
The above approach dynamically generates TypeScript definitions each time the application starts. Alternatively, it may be preferable to build a simple script to generate these on demand. For example, assume we create the following script as `generate-typings.ts`:
0 commit comments