Some Fixes (#75)

Enough7 · web-flow · commit 058e1f678431 · 2021-11-07T09:59:35.000+01:00
diff --git a/docs/1-creating-a-graphql-server-project.md b/docs/1-creating-a-graphql-server-project.md
@@ -1,4 +1,11 @@
-
+- [Create a new GraphQL server project](#create-a-new-graphql-server-project)
+  - [Register the DB Context Service](#register-the-db-context-service)
+  - [Configuring EF Migrations](#configuring-ef-migrations)
+    - [Option 1 - Visual Studio: Package Manager Console](#option-1---visual-studio-package-manager-console)
+    - [Option 2 - Command line](#option-2---command-line)
+  - [Adding GraphQL](#adding-graphql)
+  - [Adding Mutations](#adding-mutations)
+  - [Summary](#summary)
 # Create a new GraphQL server project
 
 1. Create a new project for our GraphQL Server.
@@ -202,11 +209,13 @@ Commands Explained
 
     ![Start GraphQL server](images/1-start-server.png)
 
-1. Start Banana Cake Pop and connect to our server.
+1. Start [Banana Cake Pop](https://chillicream.com/docs/bananacakepop) or use it built-in your browser at [http://localhost:5000/graphql/](http://localhost:5000/graphql/) and connect to our server (usually at [http://localhost:5000/graphql](http://localhost:5000/graphql)).   
+   **Note**: `<address>/graphql/` might **not** show mutations, make sure you use `<address>/graphql` (without trailing slash). 
 
     ![Connect to GraphQL server with Banana Cake Pop](images/2-bcp-connect-to-server.png)
 
-1. Click in the schema explorer and click on the `speakers` field in order to check the return type of the `speakers` field.
+1. Click in the schema explorer and click on the `speakers` field in order to check the return type of the `speakers` field.   
+   **Note**: You might have to reload the schema, you can do so by clicking the refresh-button in the upper-right corner. 
 
     ![Explore GraphQL schema with Banana Cake Pop](images/3-bcp-schema-explorer.png)
 
@@ -216,7 +225,7 @@ So, far we have added the Query root type to our schema, which allows us to quer
 
 > For mutations we are using the [relay mutation pattern](https://relay.dev/docs/en/graphql-server-specification.html#mutations) which is commonly used in GraphQL.
 
-A mutation consists of three components, the input, the payload and the mutation itself. In our case we want to create a mutation called `addSpeaker`, by convention, mutations are named as verbs, their inputs are the name with "Input" appended at the end, and they return an object that is the name with "Payload" appended.
+A mutation consists of three components, the **input**, the **payload** and the **mutation** itself. In our case we want to create a mutation called `addSpeaker`, by convention, mutations are named as verbs, their inputs are the name with "Input" appended at the end, and they return an object that is the name with "Payload" appended.
 
 So, for our `addSpeaker` mutation, we create two types: `AddSpeakerInput` and `AddSpeakerPayload`.
 
diff --git a/docs/2-controlling-nullability.md b/docs/2-controlling-nullability.md
@@ -1,3 +1,6 @@
+- [Controlling nullability](#controlling-nullability)
+  - [Configure Nullability](#configure-nullability)
+  - [Summary](#summary)
 
 # Controlling nullability
 
diff --git a/docs/3-understanding-dataLoader.md b/docs/3-understanding-dataLoader.md
@@ -1,3 +1,9 @@
+- [Understanding GraphQL query execution and DataLoader](#understanding-graphql-query-execution-and-dataloader)
+  - [Configure field scoped services](#configure-field-scoped-services)
+  - [Adding the remaining data models](#adding-the-remaining-data-models)
+  - [Adding DataLoader](#adding-dataloader)
+  - [Fluent type configurations](#fluent-type-configurations)
+  - [Summary](#summary)
 
 # Understanding GraphQL query execution and DataLoader
 
@@ -188,7 +194,7 @@ The GraphQL execution engine will always try to execute fields in parallel in or
 
 ## Adding the remaining data models
 
-In order to expand our GraphQL server model further we've got several more data models to add, and unfortunately it's a little mechanical. You can copy the following classes manually, or open the session 3 solution which is shown at the end.
+In order to expand our GraphQL server model further we've got several more data models to add, and unfortunately it's a little mechanical. You can copy the following classes manually, or open the [session 3 solution](/code/session-3).
 
 1. Create an `Attendee.cs` class in the `Data` directory with the following code:
 
@@ -431,7 +437,7 @@ After having everything in let us have a look at our schema and see if something
 
 1. Open Banana Cake Pop and refresh the schema.
 
-1. Head over to the schema explorer and have a look at the speaker.
+2. Head over to the schema explorer and have a look at the speaker. **Note**: You might have to reload the schema, you can do so by clicking the refresh-button in the upper-right corner.  
 
    ![Connect to GraphQL server with Banana Cake Pop](images/10-bcp-schema-updated.png)
 
diff --git a/docs/4-schema-design.md b/docs/4-schema-design.md
@@ -1,3 +1,11 @@
+- [GraphQL schema design approaches](#graphql-schema-design-approaches)
+  - [Reorganize mutation types](#reorganize-mutation-types)
+  - [Enable Relay support](#enable-relay-support)
+  - [Build out the schema](#build-out-the-schema)
+    - [Think beyond CRUD](#think-beyond-crud)
+    - [Offer plural versions fields and be precise about field names](#offer-plural-versions-fields-and-be-precise-about-field-names)
+  - [Summary](#summary)
+
 # GraphQL schema design approaches
 
 In GraphQL, most APIs are designed in Relay style. Relay is Facebook's GraphQL client for React and represents Facebook's opinionated view on GraphQL. The GraphQL community adopted the Relay server specifications since it provides a battle-tested way of exposing GraphQL at massive scale.
@@ -45,14 +53,14 @@ First, we will restructure our GraphQL server so that it will better scale once
        public class UserError
        {
            public UserError(string message, string code)
-           {
+            {
                Message = message;
                Code = code;
-        }
+            }
 
-        public string Message { get; }
+            public string Message { get; }
 
-        public string Code { get; }
+            public string Code { get; }
        }
    }
    ```
@@ -251,18 +259,19 @@ Now that we have reorganized our mutations, we will refactor the schema to a pro
 
    > The following piece of code marked our `SpeakerType` as implementing the `Node` interface. It also defined that the `id` field that the node interface specifies is implemented by the `Id` on our entity. The internal `Id` is consequently rewritten to a global object identifier that contains the internal id plus the type name. Last but not least we defined a `ResolveNode` that is able to load the entity by `id`.
 
-   > ```csharp
-   > descriptor
-   >     .ImplementsNode()
-   >     .IdField(t => t.Id)
-   >    .ResolveNode((ctx, id) => ctx.DataLoader<SpeakerByIdDataLoader>().LoadAsync(id, ctx.RequestAborted));
-   > ```
+    > ```csharp
+    > descriptor
+    >    .ImplementsNode()
+    >    .IdField(t => t.Id)
+    >    .ResolveNode((ctx, id) => ctx.DataLoader<SpeakerByIdDataLoader>()
+    >    .LoadAsync(id, ctx.RequestAborted));
+    > ```
 
 1. Head over to the `Query.cs` and annotate the `id` argument of `GetSpeaker` with the `ID` attribute.
 
    ```csharp
    public Task<Speaker> GetSpeakerAsync(
-       [ID(nameof(Speaker))]int id,
+       [ID(nameof(Speaker))] int id,
        SpeakerByIdDataLoader dataLoader,
        CancellationToken cancellationToken) =>
        dataLoader.LoadAsync(id, cancellationToken);
@@ -380,7 +389,7 @@ We will start by adding the rest of the DataLoader that we will need. Then we wi
 
 1. Now, add the missing type classes, `AttendeeType`, `TrackType`, and `SessionType` to the `Types` directory.
 
-   `AttendeeType`
+   `AttendeeType.cs`
 
     ```csharp
     using System.Collections.Generic;
@@ -641,7 +650,7 @@ We will start by adding the rest of the DataLoader that we will need. Then we wi
         .AddType<SessionType>()
         .AddType<SpeakerType>()
         .AddType<TrackType>()
-        .EnableRelaySupport());
+        .EnableRelaySupport();
     ```
 
 Great, we now have our base schema and are ready to dive into some schema design topics. Although GraphQL has a single root query type, a single root mutation type, and a single root subscription type, Hot Chocolate allows splitting the root types into multiple classes, which will enable us to organize our schema around topics rather than divide it along its root types.
diff --git a/docs/5-understanding-middleware.md b/docs/5-understanding-middleware.md
@@ -1,3 +1,9 @@
+- [Understanding middleware](#understanding-middleware)
+  - [Add UseUpper middleware](#add-useupper-middleware)
+  - [Create middleware attribute](#create-middleware-attribute)
+  - [Middleware order](#middleware-order)
+  - [Summary](#summary)
+
 # Understanding middleware
 
 The field middleware is one of the foundational components in Hot Chocolate. Many features that you use like, for instance, the `ID` transformation from internal IDs to global object identifiers, are a field middleware. Even resolvers are compiled into a field middleware.
diff --git a/docs/6-adding-complex-filter-capabilities.md b/docs/6-adding-complex-filter-capabilities.md
@@ -1,3 +1,8 @@
+- [Adding complex filter capabilities](#adding-complex-filter-capabilities)
+  - [Add paging to your lists](#add-paging-to-your-lists)
+  - [Add filter capabilities to the top-level field `sessions`](#add-filter-capabilities-to-the-top-level-field-sessions)
+  - [Summary](#summary)
+
 # Adding complex filter capabilities
 
 So far, our GraphQL server only exposes plain lists that would, at some point, grow so large that our server would time out. Moreover, we miss some filter capabilities for our session list so that the application using our backend can filter for tracks, titles, or search the abstract for topics.
diff --git a/docs/7-subscriptions.md b/docs/7-subscriptions.md
@@ -1,3 +1,11 @@
+- [Adding real-time functionality with subscriptions](#adding-real-time-functionality-with-subscriptions)
+  - [Refactor GraphQL API](#refactor-graphql-api)
+    - [Add `registerAttendee` Mutation](#add-registerattendee-mutation)
+    - [Add `checkInAttendee` Mutation](#add-checkinattendee-mutation)
+  - [Add `onSessionScheduled` Subscription](#add-onsessionscheduled-subscription)
+  - [Add `onAttendeeCheckedIn` subscription](#add-onattendeecheckedin-subscription)
+  - [Summary](#summary)
+
 # Adding real-time functionality with subscriptions
 
 For the last few parts of our journey through GraphQL, we have dealt with queries and mutations. In many APIs, this is all people need or want, but GraphQL also offers us real-time capabilities where we can formulate what data we want to receive when a specific event happens.
diff --git a/docs/8-testing-the-graphql-server.md b/docs/8-testing-the-graphql-server.md
@@ -1,3 +1,7 @@
+- [Testing the GraphQL server](#testing-the-graphql-server)
+  - [Add a schema change test](#add-a-schema-change-test)
+  - [Add a simple query tests](#add-a-simple-query-tests)
+
 # Testing the GraphQL server
 
 There are many ways to test; what we want to have a look at is how we can test parts of the GraphQL schema without writing system tests.
