chore(docs): fix various bits of tutorial content

closes #1045
closes #996
fixes issues outlined in graphql-nexus/nexus#904 (comment)

docs/tutorial/chapter-2-writing-your-first-schema.md

@@ -76,7 +76,7 @@ schema.objectType({
 
 Once you've saved this file change to disk, your app will be restarted and the previous warning you had about an empty GraphQL schema should be gone.
 
-You may notice that there's also now a new `schema.graphql` file at your project root. It contains a representation of your schema in a syntax called the GraphQL Schema Definition Language (SDL for short). In dev mode Nexus generates this for you at every app restart. In it you should see the following:
+You may notice that there's also now a new `api.graphql` file at your project root. It contains a representation of your schema in a syntax called the GraphQL Schema Definition Language (SDL for short). In dev mode Nexus generates this for you at every app restart. In it you should see the following:
 
 ```graphql
 type Post {
@@ -106,23 +106,24 @@ We'll start by letting API clients read the drafts of your blog.
 
 <!-- prettier-ignore -->
 ```ts
-// api/graphql/Post.ts     // 1
+// api/graphql/Post.ts      // 1
 // ...
 
 schema.extendType({
   type: 'Query',            // 2
   definition(t) {
-    t.field('drafts', {      // 3
-      type: 'Post',         // 4
-      list: true,           // 5
+    t.field('drafts', {     // 3
+      nullable: false,      // 4
+      type: 'Post',         // 5
+      list: true,           // 6
     })
   },
 })
 ```
 
 ```graphql
 type Query {
-  drafts: [Post!]
+  drafts: [Post!]!
 }
 ```
 
@@ -131,6 +132,10 @@ type Query {
 1. The Query object is a central place in your schema where many other types will appear. Like before with the modular GraphQL types decision we again can decide to be modular here. We could either create a new `api/graphql/Query.ts` module (not modular), or we could _collocate_ the exposure of Post object with its definition in `api/graphql/Post.ts` (modular). Staying consistent with before, we'll take the modular way.
 1. To achieve collocation in Nexus we'll use `schema.extendType`. Its API is _very_ similar to `schema.objectType` with the difference that the defined fields are merged into the _targeted_ type.
 1. The first parameter specifies the field's name, here `drafts`
+1. `nullable: false` specifies that clients will always get a value for this field. By default, in Nexus, all "output types" (types returned by fields) are nullable. This is for [best practice reasons](https://graphql.org/learn/best-practices/#nullability). In this case though we indeed want to guarantee that a list will always be returned, never `null`.
+
+   If you're ever dissatisfied with Nexus' defaults, not to worry, [you can change them](https://www.nexusjs.org/#/api/modules/main/exports/settings?id=schemanullableinputs).
+
 1. `type: 'Post'` specifies what the field's type should be. Here, a `Post`
 1. `list: true` augments the field's type spec, making it wrapped by a List type. Here, a `[Post]`. Nexus also provides the following shorthand for this 👇
 

docs/tutorial/chapter-3-adding-mutations-to-your-api.md

@@ -63,7 +63,6 @@ Now let's use this data to re-implement the `Query.drafts` resolver from the pre
 
 ```diff
 schema.queryType({
-  type: 'Query',
   definition(t) {
     t.list.field('drafts', {
       type: 'Post',
@@ -105,7 +104,7 @@ schema.extendType({
   definition(t) {
     t.field('createDraft', {
       type: 'Post',
-      nullable: false,              // 1
+      nullable: false,
       resolve(_root, args, ctx) {
         ctx.db.posts.push(/*...*/)
         return // ...
@@ -123,10 +122,6 @@ Mutation {
 
 </div>
 
-1. By default in Nexus all output types are nullable. This is for [best practice reasons](https://graphql.org/learn/best-practices/#nullability). In this case, we want to guarantee [to the client] that a Post object will always be returned upon a successful signup mutation.
-
-   If you're ever dissatisfied with Nexus' defaults, not to worry, [you can change them globally](https://www.nexusjs.org/#/api/modules/main/exports/settings?id=schemanullableinputs).
-
 We need to get the client's input data to complete our resolver. This brings us to a new concept, GraphQL arguments. Every field in GraphQL may accept them. Effectively you can think of each field in GraphQL like a function, accepting some input, doing something, and returning an output. Most of the time "doing something" is a matter of some read-like operation but with `Mutation` fields the "doing something" usually entails a process with side-effects (e.g. writing to the database).
 
 Let's revise our implementation with GraphQL arguments.
@@ -232,7 +227,7 @@ schema.extendType({
     t.list.field('posts', {
       type: 'Post',
       resolve(_root, _args, ctx) {
-        return ctx.inDb.posts.filter((p) => p.published === true)
+        return ctx.db.posts.filter((p) => p.published === true)
       },
     })
   },

docs/tutorial/chapter-5-persisting-data-via-prisma.md

@@ -16,8 +16,8 @@ Its important to understand that Nexus does not _require_ these technology choic
 
 So, what _is_ Prisma? It is an open source database toolkit that consists of the following parts:
 
-**Prisma Client**: Auto-generated and type-safe query builder for Node.js & TypeScript
-**Prisma Migrate** (experimental): Declarative data modeling & migration system
+**Prisma Client**: Auto-generated and type-safe query builder for Node.js & TypeScript  
+**Prisma Migrate** (experimental): Declarative data modeling & migration system  
 **Prisma Studio** (experimental): GUI to view and edit data in your database
 
 At the heart of Prisma is the _Prisma Schema,_ a file usually called `schema.prisma`, that you will see later in this tutorial. It is a declarative file wherein using a domain specific language you encode your database schema, connection to the database, and more.
@@ -220,12 +220,12 @@ schema.extendType({
       },
       resolve(_root, args, ctx) {
         const draft = {
--         id: ctx.inDb.posts.length + 1,
+-         id: ctx.db.posts.length + 1,
           title: args.title,
           body: args.body,
           published: false,
         }
--       ctx.inDb.posts.push(draft)
+-       ctx.db.posts.push(draft)
 
 -       return draft
 +       return ctx.db.post.create({ data: draft })
@@ -238,7 +238,7 @@ schema.extendType({
         draftId: schema.intArg({ required: true }),
       },
       resolve(_root, args, ctx) {
--       let postToPublish = ctx.inDb.posts.find((p) => p.id === args.draftId)
+-       let postToPublish = ctx.db.posts.find((p) => p.id === args.draftId)
 
 -       if (!postToPublish) {
 -         throw new Error('Could not find draft with id ' + args.draftId)

website/content/01-getting-started/03-tutorial/03-chapter-2-writing-your-first-schema.mdx

@@ -80,7 +80,7 @@ schema.objectType({
 
 Once you've saved this file change to disk, your app will be restarted and the previous warning you had about an empty GraphQL schema should be gone.
 
-You may notice that there's also now a new `schema.graphql` file at your project root. It contains a representation of your schema in a syntax called the GraphQL Schema Definition Language (SDL for short). In dev mode Nexus generates this for you at every app restart. In it you should see the following:
+You may notice that there's also now a new `api.graphql` file at your project root. It contains a representation of your schema in a syntax called the GraphQL Schema Definition Language (SDL for short). In dev mode Nexus generates this for you at every app restart. In it you should see the following:
 
 ```graphql
 type Post {
@@ -110,23 +110,24 @@ We'll start by letting API clients read the drafts of your blog.
 
 <!-- prettier-ignore -->
 ```ts
-// api/graphql/Post.ts     // 1
+// api/graphql/Post.ts      // 1
 // ...
 
 schema.extendType({
   type: 'Query',            // 2
   definition(t) {
-    t.field('drafts', {      // 3
-      type: 'Post',         // 4
-      list: true,           // 5
+    t.field('drafts', {     // 3
+      nullable: false,      // 4
+      type: 'Post',         // 5
+      list: true,           // 6
     })
   },
 })
 ```
 
 ```graphql
 type Query {
-  drafts: [Post!]
+  drafts: [Post!]!
 }
 ```
 
@@ -135,6 +136,10 @@ type Query {
 1. The Query object is a central place in your schema where many other types will appear. Like before with the modular GraphQL types decision we again can decide to be modular here. We could either create a new `api/graphql/Query.ts` module (not modular), or we could _collocate_ the exposure of Post object with its definition in `api/graphql/Post.ts` (modular). Staying consistent with before, we'll take the modular way.
 1. To achieve collocation in Nexus we'll use `schema.extendType`. Its API is _very_ similar to `schema.objectType` with the difference that the defined fields are merged into the _targeted_ type.
 1. The first parameter specifies the field's name, here `drafts`
+1. `nullable: false` specifies that clients will always get a value for this field. By default, in Nexus, all "output types" (types returned by fields) are nullable. This is for [best practice reasons](https://graphql.org/learn/best-practices/#nullability). In this case though we indeed want to guarantee that a list will always be returned, never `null`.
+
+   If you're ever dissatisfied with Nexus' defaults, not to worry, [you can change them](https://www.nexusjs.org/#/api/modules/main/exports/settings?id=schemanullableinputs).
+
 1. `type: 'Post'` specifies what the field's type should be. Here, a `Post`
 1. `list: true` augments the field's type spec, making it wrapped by a List type. Here, a `[Post]`. Nexus also provides the following shorthand for this 👇
 

website/content/01-getting-started/03-tutorial/04-chapter-3-adding-mutations-to-your-api.mdx

@@ -108,7 +108,7 @@ schema.extendType({
   definition(t) {
     t.field('createDraft', {
       type: 'Post',
-      nullable: false,              // 1
+      nullable: false,
       resolve(_root, args, ctx) {
         ctx.db.posts.push(/*...*/)
         return // ...
@@ -126,10 +126,6 @@ Mutation {
 
 </div>
 
-1. By default in Nexus all output types are nullable. This is for [best practice reasons](https://graphql.org/learn/best-practices/#nullability). In this case, we want to guarantee [to the client] that a Post object will always be returned upon a successful signup mutation.
-
-   If you're ever dissatisfied with Nexus' defaults, not to worry, [you can change them globally](https://www.nexusjs.org/#/api/modules/main/exports/settings?id=schemanullableinputs).
-
 We need to get the client's input data to complete our resolver. This brings us to a new concept, GraphQL arguments. Every field in GraphQL may accept them. Effectively you can think of each field in GraphQL like a function, accepting some input, doing something, and returning an output. Most of the time "doing something" is a matter of some read-like operation but with `Mutation` fields the "doing something" usually entails a process with side-effects (e.g. writing to the database).
 
 Let's revise our implementation with GraphQL arguments.
@@ -235,7 +231,7 @@ schema.extendType({
     t.list.field('posts', {
       type: 'Post',
       resolve(_root, _args, ctx) {
-        return ctx.inDb.posts.filter((p) => p.published === true)
+        return ctx.db.posts.filter((p) => p.published === true)
       },
     })
   },

website/content/01-getting-started/03-tutorial/06-chapter-5-persisting-data-via-prisma.mdx

@@ -20,8 +20,8 @@ Its important to understand that Nexus does not _require_ these technology choic
 
 So, what _is_ Prisma? It is an open source database toolkit that consists of the following parts:
 
-**Prisma Client**: Auto-generated and type-safe query builder for Node.js & TypeScript
-**Prisma Migrate** (experimental): Declarative data modeling & migration system
+**Prisma Client**: Auto-generated and type-safe query builder for Node.js & TypeScript  
+**Prisma Migrate** (experimental): Declarative data modeling & migration system  
 **Prisma Studio** (experimental): GUI to view and edit data in your database
 
 At the heart of Prisma is the _Prisma Schema,_ a file usually called `schema.prisma`, that you will see later in this tutorial. It is a declarative file wherein using a domain specific language you encode your database schema, connection to the database, and more.
@@ -222,12 +222,12 @@ schema.extendType({
       },
       resolve(_root, args, ctx) {
         const draft = {
--         id: ctx.inDb.posts.length + 1,
+-         id: ctx.db.posts.length + 1,
           title: args.title,
           body: args.body,
           published: false,
         }
--       ctx.inDb.posts.push(draft)
+-       ctx.db.posts.push(draft)
 
 -       return draft
 +       return ctx.db.post.create({ data: draft })
@@ -240,7 +240,7 @@ schema.extendType({
         draftId: schema.intArg({ required: true }),
       },
       resolve(_root, args, ctx) {
--       let postToPublish = ctx.inDb.posts.find((p) => p.id === args.draftId)
+-       let postToPublish = ctx.db.posts.find((p) => p.id === args.draftId)
 
 -       if (!postToPublish) {
 -         throw new Error('Could not find draft with id ' + args.draftId)