GraphQL APIs bauen

Nils Hartmann | @nilshartmann

GraphQL APIs bauen

Ein praktischer Einstieg mit Apollo Server

JavaScript Days, 20. Oktober 2022

Slides (online)

https://graphql.schule/jsdays2022

Repository

https://github.com/nilshartmann/apollo-server-workshop.git

Nils Hartmann

https://nilshartmann.net / @nilshartmann

Freiberuflicher Software-Entwickler, Berater und Trainer aus Hamburg

Java | JavaScript, TypeScript | React | GraphQL

https://graphql.schule/video-kurs

https://reactbuch.de

## Kurze Vorstellung

* Mentimeter Umfrage:
  * Link im Chat

---

## Agenda

* Teil 1: GraphQL
  * Was ist GraphQL?
  * [Die Abfragesprache](#/graphql-sprache)

* Teil 2: [GraphQL APIs bereitstellen](#/graphql-apis-bereitstellen)
  * [Das Schema Definieren](#/schema)
  * [Implementieren der API](#/api-implementieren)
    * [Resolver-Funktionen](#/resolver-funktionen)
    * [Fehlerbehandlung](#/fehlerbehandlung)
    * [Der GraphQL Context](#/graphql-context)
    * [Externe Services integrieren](#/externe-systeme-integrieren)
    * [Testen](#/testen)
    * [TypeScript](#/typescript)

---

## Zeitplan

* 09:00 bis 12:30 Teil 1
* 12:30 bis 13:30 Mittag 🍕 🍝
* 13:30 bis 17:00 Teil 2
* Zwischendurch Pausen ☕️ 🍰

---

## Grundsätzliches

* **Jederzeit:** Fragen und Diskussionen! Bringt Euch gerne ein!
* Motto: Es gibt keine dummen Fragen!
* Ich zeige viel direkt im Editor, aber ihr könnt die Slides als Referenz benutzen

---

# GraphQL

_"GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data"_ ([https://graphql.org](https://graphql.org))

---

# GraphQL

_"GraphQL is a **query language for APIs** and a runtime for fulfilling those queries with your existing data"_ ([https://graphql.org](https://graphql.org))

---

# GraphQL

_"GraphQL is a query language for APIs and a **runtime for fulfilling** those queries with your existing data"_ ([https://graphql.org](https://graphql.org))

---

# GraphQL

_"GraphQL is a query language for APIs and a runtime for fulfilling those queries with **your existing data**"_ ([https://graphql.org](https://graphql.org))

---

## Die Beispiel-Anwendung

[http://localhost:3000](http://localhost:3000)

---

## Beispiel: Sandbox

* Apollo GraphQL Browser

[http://localhost:4000](http://localhost:4000)

---

## Beispiel: GraphQL Tooling

*  IntelliJ IDEA
  *  graphql-Extension (hello.graphql)
  *  GraphQL.md im publy-Verzeichnis
  *  language=GraphQL in einer TypeScript-Datei

*  TypeScript (optional)
  *  publy-frontend, npm run codegen:watch
  *  StoryPage.query.graphql zeigen und story-Feld entfernen

---

## Spezifikation

* https://spec.graphql.org/
* Umfasst:
  * Query Sprache und -Ausführung
  * Schema Definition Language
* Kein fertiges Produkt, keine fertige Bibliothek
    * Es gibt Bibliotheken, die dir helfen, GraphQL APIs zu implementieren und bereitzustellen
    * Die abgefragten Daten müssen wir selbst ermitteln
    * GraphQL macht keine Aussage darüber, wo diese Daten herkommen (Datenbank, Micro-Service, Berechnung ...)
  
---

# Die GraphQL Abfrage-Sprache
---

### Sprache, um **Felder** aus einem **Objekt-Graphen** abzufragen

```graphql
  query {
    story {
      id title writtenBy {
        id user { name }
      }
    }
  }

---

### Felder können **Argumente** haben

<pre><code class="graphql">
  query {
    story(storyId: 5) {
      id title writtenBy {
        id user { name }
      }
    }
  }
</code></pre>

---

### Die **Antwort** sieht immer so aus, wie die Abfrage

---

### Operation-Type

Ausgeführt werden **Operationen**.
Der **Operation-Type** beschreibt, was in der Anfrage getan werden soll

* **query**: Daten lesen (Default-Operation, Schlüsselwort "query" kann weggelassen werden)
* **mutation**: Daten verändern
* **subscription**: Daten vom Server bekommen, sobald sie erzeugt wurden (ähnlich wie Events)

---

### Operation-Type

Der Operation-Type bestimmt auch den Einstiegspunkt in den Objekt-Graphen

---

### Namen von Operationen

* Operationen können **Namen** haben.
* Das ist vor allem für Debugging und Code-Generatoren relevant

* ```graphql
  query NewestStory {
      story {
        id
        title
      }
  }
  ```

---

### Fragmente

* Mit einem **Fragment** beschreibst Du eine wiederverwendbare Menge von Feldern
* ```graphql
  fragment BaseMember on Member {
      id joined
      user { is username }
  }

query {
      story {
        writtenBy { ...BaseMember }

comments {
          givenBy { ...BaseMember }
        }
      }
  }
  ```

---

### Variablen

* Queries können **Variablen** haben.
* Variablen müssen im Query deklariert werden
* Werte für Variablen werden in einem eigenen JSON-Objekt an den Server geschickt

* ```graphql
  query ($storyId: ID!) {
    story(id: $storyId) {
      id
      title body
    }
  }
  ```
* JSON mit Variablen:  
* ```json
  {
    storyId: "1"
  }
  ```
---

## Übung: Einen Query ausführen

_Mach' dich mit der GraphQL-Abfragesprache vertraut_

* Öffne GraphiQL auf meinem Computer (URL gebe ich euch)
* Versuche einen Query auszuführen, der die ersten vier Stories zurückliefert und folgende Felder abfragt:
  * Id, Titel, Excerpt, Veröffentlichungsdatum, Wer hat die Story geschrieben und die jeweils ersten zehn Kommentare
  * Kannst Du den Query so erweitern, dass er die ersten zehn _neusten_ Stories zurückliefert?
* Bau eine Fragment (`Author`), das aus dem `Member` dessen Id, sowie `fullname` und `id` des Users enthält
  * Verwende das Fragment, um in den Stories und den Kommentaren jeweils die Member-Informationen abzufragen
  * In den Stories zusätzlich noch `skills` des Members abfragen
* Die Argumente für die Felder kannst Du direkt in deinen Query schreiben oder per Variable übergeben  
* Du kannst Code-Completion und den `Docs`-Explorer (rechts oben) verwenden, um die API zu untersuchen
* Mögliche Lösungen findest Du auf den folgenden Slides.

---
## Lösung: vier Stories mit Kommentaren

```graphql
query($page: Int!, $pageSize: Int!) {
  stories(page: $page,pageSize: $pageSize) {
    stories {

id
      title
      excerpt
      createdAt
      writtenBy {
        user {
          fullname
        }
      }
      comments {
          id
          content
        }
      }
    }
  }
}
```
```json
{
  "pageSize": 4,
  "page": 0
}
```
---
## Lösung mit Sortierkriterium
```graphql
query($page: Int!, $pageSize: Int!, $sortBy: StorySortCriteria) {
  stories(page: $page,pageSize: $pageSize, sortBy: $sortBy) {
    stories {

id
      title
      excerpt
      createdAt
      writtenBy {
        user {
          fullname
        }
      }
      comments {
          id
          content
        }
      }
    }
  }
}
```
```json
{
  "page": 0,
  "pageSize": 4,
  "sortBy": {
    "field": "date",
    "direction": "desc"
  }
}
```
---
## Lösung mit Fragment
```graphql
fragment Author on Member {
  id user { fullname id }
}

query($pageSize: Int!, $sortBy: StorySortCriteria) {
  stories(pageSize: $pageSize, sortBy: $sortBy) {
    stories {
      id
      title
      excerpt
      createdAt
      writtenBy {
        ...Author
        skills
      }
      comments {
          id
          content

writtenBy { ...Author }
        }
      }
    }
  }
}
```
```json
{
  "sortBy": {
    "direction": "desc",
    "field": "date"
  },
  "pageSize": 4
}
```

---

### GraphQL Requests

*  HTTP Request an die GraphQL API
  *  request.http im publy-Ordner
  *  Fehler zeigen
---

## GraphQL Requests

* Üblicherweise nur HTTP POST-Request
  * andere HTTP Verben spielen keine Rolle
  * HTTP Status-Code meist 200 OK, auch im Fehlerfall!
  * Großer Unterscheid zu REST APIs
* Antwort-JSON-Objekt besteht aus maximal drei Feldern:
  * `data`: Die gelesenen Daten (Struktur darunter entspricht der Abfrage)
  * `errors`: Liste mit (technischen) Fehlern, u.a. Fehlermeldung
  * `extensions`: Freibelegbares Objekt für proprietäre Erweiterungen (z.B. Debug-Informationen)

---

### Union-Typen

Ein **Union-Type** kann mehr als einen Typ zurückliefern:

```graphql
  mutation  addComment
      (input: { storyId: "1", content: "..." }) {

...on AddCommentSuccessPayload {
        newComment { id }
      }

...on AddCommentFailurePayload {
        errorMessage
      }
  }
```

---
### Interfaces

* Ein Interface erzwingt gemeinsame Felder an den Objekten, die das Interface implementieren (ähnlich
    wie in Java mit Methoden)

* Beispiel: `id` und `createdAt` sind am `Node`-Interface definiert

* ```graphql
  query {
      node(id: "...") {

id
        createdAt

...on Story { title body }
        ...on Comment { content }
      }
  }
  ```

---
### Mutations und Subscriptions

* Mutations und Subscriptions sind syntaktisch wie Queries
* Bei einer Mutation werden Daten auf dem Server verändert
* Bei einer Subscription werden Daten vom Server auf den Client geschickt (Events)
---

## Übung: Mutations
* Führe eine Mutation aus, die einen neuen Kommentar erzeugt
* Du musst dazu in der Apollo Sandbox im `Headers`-Tab den Header `X-Authorization` setzen, z.B. auf `U3`
* <img src="images/auth-header.png" height="400px" />
* Frage aus der Antwort im Erfolgsfall die Id des neuen Kommentars, sowie dessen Story und deren Kommentare ab (in der Liste sollte dein neuer Kommentar nun enthalten sein)
* Im Fehlerfall frage das `errorMsg`-Feld ab
* Mögliche Lösung auf der nächsten Slide
---
## Lösung: Mutation
```graphql
mutation($input: AddCommentInput!) {
  addComment(input: $input) {
    ...on AddCommentSuccessPayload {
      newComment {
        id
         story {
           title
           comments {
             id
             content
           }
         }
      }
    }
    ...on AddCommentFailedPayload {
      errorMsg
    }
  }
}
```
```json
{
  "input": {
    "content": "Neuer Kommentar",
    "storyId": "7"
  }
}
```
---
### Teil II

# GraphQL APIs bereitstellen

---

### Das GraphQL Schema

* GraphQL APIs müssen in einem Schema beschrieben werden.
* In dem Schema werden Objekte (Typen) mit Feldern beschrieben.
* Das Schema selbst ist zur Laufzeit mit einem _Introspection Query_ abfragbar
  * 🧑‍💻 Beispiel im Playground
* Mit der [Schema Definition Language](https://graphql.org/learn/schema/)

---

### Die SDL

*  Demo: Schema-Definition 
  *  ping-Feld mit Message Object
  *  Argument!
  *  Rückgabewert-String
  *  Doku

---

### Die SDL

Beschreibung eines *Objekt Types*

<pre><code class="graphql">
  type Story {
    id: ID!

title: String!
    body: String!
  }
</code></pre>

* Beschrieben werden **Felder** mit **Return Types**
* Ein Ausrufezeichen zeigt an, dass das Feld nicht _nullable_ ist

---

### Dokumentation und Kommentare

* Dokumentation mit drei doppelten Anführungszeichen
  * Markdown zur Formatierung erlaubt
* Kommentare mit Hash-Zeichen
  * Dokumentation ist Bestandteil der API, Kommentare nicht

* ```graphql
  """
  A `Story` is the main object in our service.
  """
  type Story {
    """Identifies this object"""
    id: ID!

# todo: implement new tags-field (PROJ-666)
  }
  ```

---

## Skalare Typen

* Skalare Typen entsprechen primitiven Typen in JavaScript
  * Sind die Enden im Objekt-Graphen
* Standard-Typen: ID, String, Boolean, Int, Float
  * ID wird als String gelesen und geschrieben, soll aber nicht interpretiert werden

* ```graphql
  type Member {
    id: ID!

username: String!

# no exclamation mark: can be null
    likes: Int

amount: Float!

activeMember: Boolean
  }
  ```

* Man kann eigene skalare Typen bauen
---

### Aufzählungstypen (enum)

* Wie in TypeScript

* 
  ```graphql
  enum ReactionType {
    like,
    laugh,
    thumbUp
  }
  ```

---

### Referenzen

* Referenzen auf andere Objekt-Typen

* 
  ```graphql
  type Member {
    # ...
  }

type Comment {
    # ...
  }

type Story {
    """Reference to the Member that has written this Story"""
    writtenBy: Member!

comments: [Comment!]!

}
  ```

---

### Argumente

* Felder können Argumente haben
  * Solche Felder werden auch _Methoden_ genannt
* Die Felder mit ihren Namen und Typen müssen in der API definiert werden
  * Namen sind entscheidend (wie in Objekten an Funktionsparametern in JS), nicht Reihenfolge (wie in JavaScript)
* Argumente können Default-Werte haben
* Achtung! Argumente dürfen keine Objekt-Typen sein!

* ```graphql
  type Story {

# Mandatory argument maxLength, defaults to 20
    #  if not specified by the client
    excerpt(maxLength: Int! = 20): String!

}
  ```

---

### Root-Typen

* Root-Typen bilden den Einstiegspunkt für Queries in den Objekt-Graphen
* Root-Typen sind **Query**, **Mutation** und **Subscription**
  * **Query** ist Pflicht, die beiden anderen Typen optional
* Syntax und Verhalten genauso wie bei Objekt-Typen
* Felder an den Root-Typen werden auch **Root-Felder** genannt

* ```graphql
  type Query {
    """Returns a List of all stories"""
    stories: [Story!]!

"""Returns a story by its ID or null"""
    story(id: ID!): Story
  }

type Mutation {
    addComment(storyId: ID!, memberId: ID!, content: String!): Comment!
  }
  ```
---

### Input-Typen

* Objekt-Typen können nicht als Argument an ein Feld übergeben
* Als Argumente an Feldern können nur skalare Typen, Enums und Input-Typen übergeben werden.
* Ein Input-Type wird mit `input` definiert, sieht ansonsten aus wie ein Objekt-Type
  * Ein Input-Type darf keine Objekt-Typen referenzieren

* ```graphql
  input AddCommentInput {
    storyId: ID!
    memberId: ID!
    content: String!
  }

type Mutation {
    addComment(input: AddCommentInput!): Comment!
  }
  ```

---

### Union Types

* Union Types bilden eine Menge von anderen Typen
* Ein Feld kann ein Typen aus dieser Menge zurückliefern ("A _oder_ B")

* ```graphql
  type AddCommentSuccess { newComment: Comment! }
  type AddCommentFailed { errorMessage: String! }

union AddCommentResult = AddCommentSuccess | AddCommentFailed

type Mutation {
    addComment(input: AddCommentInput!): AddCommentResult!
  }
  ```

---

### Interfaces

* Mit einem Interface wird erzwungen, dass Objekte über gleiche Felder verfügen
  * Vergleichbar mit Interfaces in TypeScript

* ```graphql
  interface Node {
    id: ID!
  }

type Story implements Node {
    id: ID!  # Field defined in Node-Interface

title: String! # additional Story fields
  }

type Comment implements Node {
    id: ID!

content: String!
  }

type User {
    id: ID!
    email: String
  }

type Query {
    # Returns either Story or Comment, but not User

node(id: ID!): Node 
  }
  ```

---

### Schema-Evolution

* In GraphQL gibt es nur _eine Version_ der API (kein `/api/v1`, `/api/v2`)
* Das Schema kann jederzeit erweitert werden
  * Clients fragen explizit Felder ab, d.h. durch neue Felder werden sie nicht beeinträchtigt
* Man kann Felder mit `deprecated` markieren, um anzuzeigen, dass sie nicht genutzt werden sollen

* ```graphql
  type Query {
    # Ausgangspunkt 
    getStoryById(id: ID!): Story
  }
  ```

* ```graphql
  type Query {
    getStoryById(id: ID!): Story

# Neues Feld, beeinträchtigt bestehenden Client nicht
    stories: [Story!]!
  }
  ```

* ```graphql
  type Query {
    getStoryById(id: ID!): Story @deprecated("Use story instead")
    story(id: ID!): Story

stories: [Story!]!
  }
  ```
---
### _Eine_ API für ganze Anwendung

* Üblicherweise hat eine Anwendung *eine* GraphQL API
  * In REST gibt es mehrere Endpunkte, die auf unterschiedliche Server verteilt sein können
  * GraphQL soll zentrale API sein
  * Untereinander kommunizieren die Services per REST o.ä.
---

### Übung: Schema beschreiben

---

### Vorbereitung: Das Repository

* Repository klonen: `git clone https://github.com/nilshartmann/apollo-server-workshop.git`
* `workspace`: Hier arbeiten wir, bitte in der IDE öffnen
* Darin `pnpm install` ausführen
  * `pnpm` könnt ihr mit `corepacks enable` einschalten oder es [manuell installieren](https://pnpm.io/installation)
* Dann `pnpm dev` zum Starten ausführen
* Das Projekt ist in TypeScript geschrieben, sollte aber auch mit JavaScript-Syntax funktionieren.
* `steps`: Lösungen für die einzelnen Übungen

---
### Übung: Schema beschreiben
* 
* Vervollständige die Datei `src/graphql/schema.graphql` und beschreibe darin eine API, die folgende Objekt-Typen enthält:
  * **Member** mit `id` und `profileImage`
  * **Story** mit `id`, `title`, `body`, `excerpt` und einer Referenz (`writtenBy`) auf den Member
    * Das `excerpt`-Feld soll ein Argument haben: `maxLength` vom Typ int (Pflicht)
  * Alle Felder in den beiden Typen sind Pflicht (non-nullable), das `id`-Feld ist vom Typ `ID` alle anderen Strings
* Lege den Query-Typen mit folgenden Feldern an:
  * `allStories`: Liefert eine Liste der `Story`-Objekte zurück. Nicht nullable.
  * `story`: Liefert eine einzelne Story zurück. Das Feld soll ein Argument haben: `storyId`. Das Feld kann `null` zurückgeben
* Füge für das `story`-Feld Dokumentation hinzu
* In der "Apollo Sandbox" (http://localhost:4000/graphql) kannst Du deine API sehen und Queries formulieren, das Ausführen funktioniert natürlich noch nicht
* Eine mögliche Lösung findest Du in `steps/01-schema`

---

## Implementieren der GraphQL API

---

### Apollo Graphql

* Ursprünglich Open-Source GraphQL Server und Client
* Apollo bietet mittlerweile (kommerzielle) Services für alles rund um GraphQL an
* Vermarkten auch proprietäre Ideen, wie Federation, "GraphOS" und "Supergraph"

---
### Apollo Server

* https://www.apollographql.com/docs/apollo-server/
  * "All-inclusive"-Lösung
  * "Standalone" Server oder als Middleware für Express
  * Integration in andere Webserver (wie Hapi) ändern sich von Version zu Version
  * Basiert auf der "reinen" JavaScript Referenz-Implementierung [graphql-js](https://github.com/graphql/graphql-js)
* [Apollo Sandbox](https://www.apollographql.com/docs/studio/explorer/sandbox/) zur Ausführung von Queries
  * Achtung! Tracking!
  * Prominente Open-Source-Alternative: [GraphiQL](https://github.com/graphql/graphiql)
* Caching von Ergebnissen
* Automatic persisted queries: Queries per ID ausführen
* "Federation": Zusammenführen verschiedener GraphQL APIs

---

### Verarbeitung eines GraphQL Queries (allgemein)

1.  Query kommt an (HTTP Endpunkt)
2. Query wird geparst und validiert
3. Ungültige Queries werden abgewiesen (`errors`-Feld in der Antwort)
4. Für jedes Feld wird eine *Resolver-Funktion* aufgerufen, die verantwortlich dafür ist, die Daten für das jeweilige Feld zu liefern
5. Die Ergebnisse der Resolver werden validiert (insb. hinsichtlich der Typen)
6. Das Ergebnis wird als `data`-Feld bereitsgestellt
7. Das Ergebnis wird an den Client zurückgeschickt

*  Unsere Aufgabe ist es, die Resolver-Funktionen zu implementieren
---

### Apollo Server

* **Konfiguration und Start** über `ApolloServer`-Objekt
* Der Server erwartet ein *executable Schema* (Schema-Beschreibung und Resolver-Funktionen)
* Je nach Laufzeitumgebung kann der Server standalone laufen (Express integriert) oder explizit in eine
            vorhandene Express Instanz integriert werden
* ```javascript
  import { ApolloServer } from "@apollo/server";

const typeDefs = /* später */
  const resolvers = /* später */

const schema = makeExecutableSchema({ typeDefs, resolvers });
  const app = express();
  const httpServer = http.createServer(app);
  const server = new ApolloServer({
      schema,
  });

await server.start();

app.use("/graphql",
      expressMiddleware(server)
  );

httpServer.listen({ port: 4000 });
  ```

---

### Bereitstellen des Schemas

* Das Schema wird grundsätzlich mit der SDL beschrieben
* Entweder in externer Datei oder direkt im Source-Code
* Beispiel 1: Direkt im Source Code
  * ```javascript
  // language=GraphQL
    const typeDefs = `
      type Query { ping: String! }
    `
  ```
* Beispiel 2: Aus Datei lesen
  * ```javascript
  const typeDefs = readFileSync(
    path.resolve(__dirname, "graphql/schema.graphql"),
    "utf8"
  );
  ```

---

### Resolver-Funktionen

* **Ein Resolver liefert den Wert für ein angefragtes Feld in einer Operation**
* Zwingend erforderlich für jedes Root-Field (in den Query, Mutation und Subscription-Types)
  * falls keine Resolver-Funktion hinterlegt ist für ein Feld, greift ein Default Resolver
  * der Default-Resolber ermittel die Werte an Hand von Feldern oder Funktionen an Objekten
* Ein Resolver kann einen Wert zurückliefern oder ein Promise für den Wert

---

### Beispiel: Resolver-Funktionen

*  Demo: Resolver- mit Person-Feld
*  Schema-Mapping! (fullname)
*  Argumente!

---

### Resolver-Funktionen
* Resolver werden in der *Resolver Map* gehalten. Das ist ein JavaScript-Objekt:
* Key darin ist der Name eins GraphQL Objekts (z.B. `Query` oder `Story`)
* Als Wert dazu ist ein weiteres Objekt mit den Resolver-Funktionen hinterlegt:
  * In diesem Objekt ist der Key der Name eines Feldes an dem GraphQL Typen
  * Der Wert ist eine Funktion, die den Wert für das Feld ermittelt
* Beispiel für einen *Root*-Resolver:
  * ```javascript
    const resolvers = {
      Query: {
        ping: () => "Hello World"
      }
    }
    ```
---
### Resolver-Funktionen
* Signatur 1: `feldname(source, args, context, info): Wert`
* Signatur 2: `feldname(source, args, context, info): Promise<Wert>`
* Resolver-Funktionen können drei Argumente entgegennehmen:
  1. Das Source- oder Parent-Objekt
  2. Die für das Feld übergebenen Argumente
  3. Das GraphQL Context-Objekt
  4. Meta-Informationen über den Query
---

### Resolver-Funktionen: Argumente

* Die an ein Feld übergebenen Argumente werden in einem Objekt an das _zweite_ Argument des Resolvers übergeben
* Es werden nur Werte übergeben, die gemäß Schema gültig sind
  * Bei nicht gültigen Werten wird der Query abgelehnt
* ```graphql
  type Story { id title body }

type Query {
    story(storyId: ID): Story
  }
  ```
* ```javascript
  const resolvers = {
    Query: {
      story(_, { storyId }) {
        return db.getStoryById(storyId);
      },
    }
  }
  ```
---
### Resolver-Funktionen: Das Parent-Objekt
* Alle nicht-Root-Resolver bekommen ihr jeweiliges Parent-Objekt als ersten Parameter übergeben
* Das Parent-Objekt ist das Objekt, das der vorherige Resolver zurückgeliefert hat
* ```graphql
  type Story {
    id title body
    excerpt(maxLength: Int! = 10)  # excerpt nicht am JavaScript Story Object!
  }

type Query {
    story(storyId: ID!): Story
  }
  ```
* ```javascript
  const resolvers = {
    Query: { /* wie gesehen... */ },
    Story: {
      excerpt(story, { maxLength } ) {
        return story.body.substring(0,maxLength);
      }
    }
  }
  ```
---
### Resolver-Funktionen: Das Context-Objekt
* Mit dem Context-Objekt können Informationen pro Query erzeugt und an alle Resolver übergeben werden
  * Zum Beispiel Header aus dem HTTP Request (Authorization, ...)
* Mehr dazu später
---
### Resolver für Mutations

* Resolver für den Mutation-Typen werden ebenfalls in die ResolverMap aufgenommen.
* Signatur der Funktionen ebenfalls identisch
* Einziger (semantischer) Unterschied: in den Mutation Resolvern dürfen Daten verändert werden
* ```javascript
  const resolvers = {
    Query: { /* ... */ },

Mutation: {
      addComment(_, { input }) {
        return publyDomainService.addCommentToPost(input.storyId, input.content);
      }
    }
  }
  ```
---
### Resolver registrieren

* Die Resolver werden an die `ApolloServer`-Instanz übergeben
  * Entweder als `executableSchema`
    * ```javascript
      const resolvers = { Query: { /* ... */ } };
      const schema = makeExecutableSchema({ typeDefs, resolvers });
      const server = new ApolloServer({
        schema,
        // ...
      })
      ```
  * Oder als eigene Konfigurationsoption
    * ```javascript
      const resolvers = { Query: { /* ... */ } };
      const server = new ApolloServer({
        typeDefs,
        resolvers
        // ...
      })
      ```
---
### Resolver modularisieren
* Natürlich könnt ihr die Resolver auch auf unterschiedliche Module aufteilen
* Beispiel:
  * ```javascript
    import { queryResolvers } from "./query.resolver"; // { story() { ... } }
    import { storyResolvers } from "./query.resolver"; // { excerpt() { ... } }

const resolvers = {
      Query: queryResolvers,
      Story: storyResovers
    }

const server = new ApolloServer({
        typeDefs,
        resolvers
        // ...
    })
    ```
---

### Übung: Resolver implementieren

* **Implementiere die Resolver für `Query.allStories`, `Query.story` und `Story.excerpt`**
* Du musst die Änderungen in `src/graphql/resolver.ts` machen (Du brauchst keine TypeScript-Typen hinschreiben)
* Zum Ermitteln der Story bzw. Stories kannst Du den `publyDomainService` verwenden, der aus `src/domain/PublyDomainService.ts` exportiert wird
* Das `Story.excerpt` Feld soll die ersten `maxLength` Zeichen aus dem `body`-Feld Story zurückliefern. (Erinnerung: `maxLength` ist ein Argument am `excerpt`-GraphQL Feld)
* Falls Du mit der Übung 1 (Schema beschreiben) nicht fertig geworden bist, kopiere dir `steps/01-schema/src/graphql/schema.graphl`
          in dein Workspace-Verzeichnis
* Wenn Du die drei Resolver korrekt implementiert hast, müssen die Queries auf der folgenden Slide funktionieren
* Eine Lösung findest Du im Verzeichnis `steps/02-resolver`

---
### Übung: Resolver #2
* Der folgende Query sollte funktionieren, wenn Du den Resolver für `allStories` korrekt implementiert hast:
  * ```graphql
    query {
      allStories {
        id title body
        writtenBy { id profileImage }
      }
    }
    ```

* Der Query sollte funktionieren, wenn Du den `Query.story`-Resolver implementiert hast:
  * ```graphql
    query {
      story(storyId: "1") {
        id title body
        writtenBy { id profileImage }
      }
    }
    ```
* Der Query sollte funktionieren, wenn Du den `Story.excerpt`-Resolver implementiert hast (die Werte für
            das `excerpt`-Feld sollten dann natürlich max. zehn Zeichen lang sein 😉
  * ```graphql
    query {
      allStories {
        id
        title
        excerpt(maxLength: 10)
      }
    }
    ```
---
### Fehlerbehandlung

* Was ist an folgender API problematisch?
* ```graphql
  input AddStoryInput {
    title: String!
    body: String!
  }

type Mutation {
    addStory(input: AddStoryInput!): Story!
  }
  ```
* Es wird *immer* ein Story-Objekt zurückgegeben!
* Was passiert, wenn die Story nicht angelegt werden konnte?

---

### Resolver: Union-Types

* Wenn ein Resolver einen Union-Typen zurückliefert, muss Apollo wissen, welchem GraphQL-Typen dein Resolver-Ergebnis entspricht
* Beispiel Mutation:
  * ```graphql
    type AddStorySuccess { storyAdded: Story! }

type AddStoryFailed { error: String! }

union AddStoryResponse = AddStorySuccess | AddStoryFailed

type Mutation {
      addStory(input: AddStoryInput!): AddStoryResponse!
    }  
    ```
* Apollo muss wissen, ob das zurückgelieferte (JavaScript-)Objekt vom Resolver für `Mutation.addStory` dem GraphQL Typen `AddStorySuccess` oder `AddStoryFailed` entspricht
* Dazu musst Du einen Resolver mit dem Namen `__resolveType` bauen und zwar für den Union-Typen (hier also `AddStoryResponse.__resolveType`)
* Diese Funktion wird dann mit dem Ergebnis eines Resolvers aufgerufen, der den Union-Typen zurückgegeben hat (`Mutation.addStory`)
* Die Resolver-Funktion muss dann prüfen, um welche konkrete Ausprägung des Union-Types es sich handelt und den Namen des GraphQL-Typen als String zurückliefern (`"AddStorySuccess"` oder `"AddStoryFailed"`)

---
### Resolver: Union-Types

* Beispiel:
* ```javascript
  const resolvers = {
    // ...
    AddStoryResponse: {
      __resolveType(addStoryResult) {

// Annahme: das addStoryResult JS-Objekt enthält
        // ein Feld "storyAdded", wenn es ein "erfolgreiches"
        // Ergebnis ist.

if ("storyAdded" in addStoryResult) {
          return "AddStorySuccess";
        }
        return "AddStoryFailed";
      },
    },
  }
  ```
---

---
## Übung: Mutations und Union Types
* **Implementiere die Resolver-Funktion für die `addComment`-Mutation**
*  Bitte das erweiterte Schema aus `material/comment-schema.graphql` kopieren und ans Ende deiner `src/graphql/schema.graphql`-Datei kopieren
*  Implementiere den fehlenden Resolver: `Mutation.addComment` in `resolver.ts`
  * Zum Speichern des Kommentars kannst Du `publyDomainService.addComment` aufrufen. Übergib für den `userId`-Parameter im ersten Schritt einfach `U3`
  * Wenn ein Fehler fliegt, fange diesen mit `catch` auf und gib den Fehlertypen (`AddCommentFailedPayload`) mit einer Fehlermeldung zurück. 
  * (Du kannst zum Testen einen Fehler provozieren, in dem Du einen Kommentar anlegst, der weniger als fünf Zeichen lang ist)
  * Im Erfolgsfall gib den neuen Kommentar als `AddCommentSuccessPayload`-Typen zurück
* Implementiere außerdem den `__resolveType`-Resolver für den Union-Typen `AddCommentPayload`
*  Wenn alles korrekt implementiert ist, sollten die beiden Mutations auf der folgenden Seite funktionieren.
---

### Übung: Union Types

* Funktionierende Mutation (`newComment` sollte gefüllt sein):
* ```graphql
  mutation {
    addComment(input: {
      content: "Toller Artikel!",
      storyId: "2"
    }) {
      ...on AddCommentFailedPayload { errorMsg }

...on AddCommentSuccessPayload {
        newComment {
          id 
          story { id }   
          writtenBy { id }
        }
      }
    }
  }
  ```
* Mutation, die das `errorMsg` mit einer Fehlermeldung füllen soll:
* ```graphql
  mutation {
    addComment(input: {
      content: "Toll",
      storyId: "2"
    }) {
      ...on AddCommentFailedPayload { errorMsg }

...on AddCommentSuccessPayload {
        newComment {
          id 
          story { id }
          writtenBy { id }
        }
      }
    }
  }
  ```

---
### Fehlerbehandlung

* Zwei Arten:
  * Ein Feld gibt ein "fachliches" Fehler-Objekt zurück (wie gesehen, z.B. `AddStoryFailed`)
  * Nicht behandelte (technische) Fehler werden über das `errors`-Objekt an den Client geschickt
    * (trotzdem HTTP Status Code 200!)
* Das `errors`-Feld ist nicht genau spezifiziert und dessen Inhalt kann auch nicht im Schema beschrieben werden
* Deswegen sollte es nur für Ausnahmen verwendet werden, z.B. wenn der Query gar nicht ausgeführt werden kann, zum Beispiel, weil der Query ungültig ist:
* ```json
  {
    "data": {},
    "errors": [
      {
        "message": "Cannot query field 'cmment' on type 'AddCommentSuccessPayload'.",
        "locations": [ { "line": 4, "column": 7 }
        ],
        "extensions": {
          "code": "GRAPHQL_VALIDATION_FAILED",
        }
      }
    ]
  }
  ```
---

### GraphQLErrors

* Neben dem Fehler (`message`) und der Angabe, bei welchem Feld im Query ein Fehler (`locations`) aufgetreten ist, gibt es ein `extensions`-Feld, das von GraphQL Servern
befüllt werden kann.
* Apollo sendet darin einen `code` und ggf. den Stacktracke
* Das `extensions`-Feld kannst Du selbst setzen, in dem du einen `GraphQLError` in deinem Resolver wirfst.
  * Der `GraphQLError` erwartet im Konstruktor die Fehlermeldung und ggf. ein eigenes `extensions`-Objekt:
  * ```javascript
      throw new GraphQLError("Please log in", {
        extensions: {
          code: "INVALID_CREDENTIALS",
          requestId: "4129374981234"
        },
      });
      ```
  * Ergebnis:      
  * ```json
    {
      "errors": [
        {
          "message": "Please log in",
          "locations": [ { "line": 4, "column": 7 } ],
          "extensions": {
            code: "INVALID_CREDENTIALS",
            requestId: "4129374981234"
          }
        }
      ]
    }
    ```

---
## Der GraphQL Context
---
### Der GraphQL Context

* Vor jeder Ausführung eines GraphQL Requests vom Client kannst Du ein Context-Objekt erzeugen
* Das Context-Objekt ist ein reguläres JavaScript-Objekt, das Du nach deinen Anforderungen befüllen kannst
* Das Context-Objekt wird jeder Resolver-Funktion übergebeen, die im Zuge des Requests aufgerufen wird.
* Typische Verwendung zum Beispiel zum Übergeben des angemeldeten Benutzers oder auch Zugriff auf Daten-Quellen (z.B. DB Verbindung)

---

### Der GraphQL Context

*  <code>X-Authorization</code> aus Request-Header lesen
*  Im <code>ping</code>-Resolver auslesen

---

### Der GraphQL Context

* Deine Funktion zum Erzeugen des Context-Objektes wird von Apollo vor jedem Request ausgeführt
* Der `context`-Funktion wird ein `config`-Objekt übergeben. Wie das genau aussieht, hängt von der Server-Konfiguration und den verwendeten Plug-ins ab
  * In der Regel hast Du aber zumindest das Express Request (`req`) und Response (`res`) Objekt darin
* Die Funktion muss ein Promise mit deinem Context-Objekt aufrufen
* ```javascript
  async function createPublyContext(config) {
    const userIdFromHttpHeader = config.req.get("X-Authorization") || null;

// In "echter" Anwendung wäre die User-Id ein Token
    // das wir hier vielleicht auch noch validieren würden...

const context = {
      userId: userIdFromHttpHeader
    };

return context;
  }
  ```
---
### Der GraphQL Context
* Die Funktion kannst Du entweder direkt am `ApolloServer` oder in der `expressMiddleware` angeben:

* ```javascript
  const app = express();
  const server = new ApolloServer({ /* ... */ });
  // ...

app.use(
    "/graphql",
    cors(), json(),
    expressMiddleware(server, { context: createPublyContext })
  );
  ```  
* In unserer Beispiel-Anwendung geben wir die `context`-Funktion bei der `expressMiddleware` an, weil wir später auch den Apollo Cache benötigen, auf den wir
  nur dort Zugriff haben. Ansonsten ginge auch:
* ```javascript
  const app = express();
  const server = new ApolloServer({ 
    // ...
    context: createPublyContext
  });
  // ...
  ```  
---
### Übung: GraphQL Context

*   
* **Verwende den GraphQL Context, um die userId an die Resolver zu übergeben. Stelle im `addComment`-Resolver sicher, dass die `userId` gesetzt ist**
* Erzeuge in `start-graphql-server.ts` eine neue Funktion `createPublyContext`, die den Kontext erzeugt
* Die Funktion erwartet einen Parameter (`config`), der den HTTP Request und Response enthält.
* Die Funktion soll ein Objekt zurückliefern, das einen Eintrag enthält `userId`:
  * Das ist entweder der Wert, der im HTTP-Header `X-Authorization` steht
  * oder `null`, falls der Request keinen solchen Header hat.
* Füge die Funktion als `context`-Eigenschaft dem zweiten Parameter von `expressMiddleware` hinzu
  * `expressMiddleware(server, { context: createPublyContext }))`  
* Im Resolver für `addComment` liest Du die `userId` aus.
  * Wenn die userId gesetzt ist, soll diese userId für den Aufruf von `publyDomainservice.addComment` verwendet werden.
  * Wenn keine `userId` gesetzt, einen GraphQL-Fehler erzeugen, so dass das `errors`-Objekt in der Antwort gefüllt wird (mit Fehlercode `NOT_LOGGED_IN`) 
* Den Header kannst Du zum Testen im `Headers`-Tab in der Apollo Sandbox setzen. Beispiel User-Id: `U3`.
  * <img src="images/auth-header.png" style="height:200px"/>
* Eine Lösung findest Du in `steps/04-context`

---

## Daten aus anderen Systemen integrieren

---

### Daten-Quellen

* Weder die GraphQL Spezifikation noch Apollo machen eine Aussage/stellen eine Anforderung, wo die Daten herkommen müssen
* Wir können beliebige Datenquellen (DB, REST APIs, andere GraphQL APIs) in unseren Resolvern verwenden, um die benötigten Daten zu ermitteln
* Ihr könnt also einfach Eure Lieblingslibraries benutzen, die ihr ohnehin schon für den Zugriff auf Datenbank etc. benutzt

* Aber es gibt ein paar Klippen beim Zugriff auf externe Systeme!
* Performance 😱

---

### Caching

* Wir können Felder im Schema mit der Direktive `cacheControl` markieren
* Damit können wir steuern, wie lange ein Feld "gültig" ist
  * Apollo fügt dann einen `Cache-Control`-Header in Eure Antwort ein
  * Mit dem `responseCachePlugin` kann die Antwort auch im Server gecached werden
    * Der entsprechende Resolver wird dann nicht aufgerufen, sondern der Wert wird aus dem Cache geliefert
* Wenn mehrere Felder in einem Query abgefragt sind, die im Schema mit `cacheControl` als cachebar gekennzeichnet sind,
entscheidet die kürzeste Cache-Dauer

*  Cache-Control am ping-Feld mit Zeitstempel Datum
*  HTTP Header
*  responseCachePlugin (@apollo/server-plugin-response-cache)

---
### Laufzeitverhalten

* Architektur der Anwendung: User kommen aus einem Microservice 
* Was passiert bei diesem Query?
* ```graphql
  query {
    allStories {   # Story
      writtenBy {  # Member
        user {     # User
          id fullname
        }
      }
    }
  }
  ```
* ```javascript
  const resolvers = {
    Query: { 
      allStories() { return publyDomainService.findAllStories() }
    },
    Member: {
      user(member) {
        // HTTP Request zu Microservice
        return userRestService.getUserForId(member.user_id)
      }
    }
  }
  ```
* *1+n-Problem 😱*  
---
### Laufzeitverhalten

* *1+n-Problem 😱*  
* ```javascript
  const resolvers = {
    Query: { 
      allStories() { return publyDomainService.findAllStories() } // EIN Datenbankzugriff (liefert n Stories)
    },
    Member: {
      user(member) {
        return userRestService.getUserForId(member.user_id) // n REST-Aufrufe (1x pro Story-Member)
      }
    }
  }
  ```

---
### Apollo RESTDataSource

* `RESTDataSource` kann für den Zugriff auf externe Systeme per REST API verwendet werden
* Kann Antworten cachen
* Gab bis Apollo Server v3 [weitere DataSource-Implementierungen](https://www.apollographql.com/docs/apollo-server/v3/data/data-sources), u.a. für SQL. Scheinen in v4 entfernt worden zu sein.
*  Beispiel: DataSource für UserService
*  Beispiel: Requests werden gecached
*  Beispiel: Caching der Ergebnisse mit HTTP Header

---

### RESTDataSource

* Abstrakte Oberklasse im Package `@apollo/datasource-rest`
* Property `baseURL` setzen
* An der Klasse sind Hilfsfunktionen zum Ausführen von HTTP Requests vorhanden
  * `this.get`, `this.post`
* Eigene abgeleitete Klasse anlegen und mit fachlichen Funktionen ergänzen
* ```javascript
  import { RESTDataSource } from "@apollo/datasource-rest";

export default class UserServiceDataSource extends RESTDataSource {
    baseURL = "http://localhost:4010/";

getUser(userId) {
      return this.get(this.baseURL + "users/" + userId);
    }
  }
  ```
* In der Regel werden die DataSources über den Context an die Resolver übergeben
* ```javascript
  async function createPublyContext(cache) {
    // ...
    const userServiceDataSource = new UserServiceDataSource();

return {
      userId,
      datasources: {
        userServiceDataSource,
      },
    };
  }
  ```

---
### RESTDataSource: Verhalten anpassen

* Per Default wird der HTTP Request an die gegebenene URL gesendet
* Tritt dabei ein Fehler auf (technisch oder HTTP !== 2xx), wird ein Fehler geworfen
* Mit `willSendRequest` bzw. `didReceiveResponse` kann das Verhalten angepasst werden
  * Zum Beispiel setzen von HTTP Headern vor dem Absenden
  * Oder abweichende Fehlerbehandlung
* ```javascript
  export default class UserServiceDataSource extends RESTDataSource {
    // ...

willSendRequest(opts) {
      opts.headers['X-Authorization'] = "mytoken"
    }

didReceiveResponse(response, _request) {

if (response.status === 404) {
        return Promise.resolve(null);
      }

return super.didReceiveResponse(response, _request);
    }
  }
  ```

---
### RESTDataSource: Request Caching

* Die Ergebnisse eines GET-Requests werden per Default in der DataSource-Instanz gecached
  * Requests mit identischer URL gelten als gleich, die URL wird per Default als Cache-Key verwendet
  * Abschalten mit `memoizeGetRequests = false`
  * Da die Instanz an den Lebenszyklus eines GraphQL Queries gebunden ist, gilt der Cache nur für einen Query
---
### RESTDataSource: Response Caching

* Wenn der angefragte Service einen `Cache-Control` HTTP-Header zurückliefert, wird das Ergebnis ebenfalls gecacht
  * So lange, bis es gemäß des Headers gültig ist
* Dazu muss der Cache der Apollo Server-Instanz verwendet werden
  * Dieser ist dann auch Query-übergreifend (und auch Client-übergreifend) gültig
  * Es gibt mehrere Implementierungen, per Default In-Memory (LRU)
* Die verwendete Cache-Instanz kann über die laufende Server-Instanz abgefragt werden (`server.cache`) und an
  den Konstruktor der DataSource übergeben werden
* ```javascript
  const server = new ApolloServer({ /* ... */ });
  //...

await server.start();
  // ...

const userServiceDataSource = new UserServiceDataSource(
    {cache}
  ));
  ```

---
### Übung: RESTDataSource

* **Implementiere eine RESTDataSource, die die User aus unserem remote UserService liest**
* Vorbereitung: Starte den UserService (`pnpm start` in `app/userservice`)
* Schritt 1: Lege die Klasse `UserServiceDataSource` an
  * Die URL zum Abfragen eines Users lautet: http://localhost:4010/users/USERID
  * Die Klasse soll eine Methode bekommen, mit der ein User an Hand seiner ID abgefragt werden kann.
  * Erweiter die `createPublyContext`-Funktion, erzeuge dort eine Instanz der UserServiceDataSource.
  * Füge die Instanz dem GraphQL Context hinzu.
* Schritt 2: Implementiere den Resolver für `Member.user`
  * Das erweiterte Schema findest Du in `material/member-schema.graphql`. Kopiere es an dein bestehendes Schema.
  * In `resolvers` implementiere den Resolver für `Member.user`
  * Das Parent-Objekt `member` hat ein Feld `userId`. Mit diesem Wert musst du deine UserServiceDataSource aufrufen.
* Der Query auf der folgenden Seite sollte dann funktionieren und einen User zurückliefern.

---
### Übung: RESTDataSource

* Wenn die UserServiceDataSource korrekt funktioniert, sollte dieser Query funktionieren:
* ```graphql
  query {
    story(storyId: "1") {
      title
      writtenBy {
        user { id fullname login }
      }
  
      comments {
        writtenBy {
          user { id fullname login }
        }
      }
    }
  }
  ```
* Sowohl der `user` in der Story als auch die User in den Kommentaren sollten zurückgeliefert werden.

---
## Testen

---

### Optionen

* Resolver direkt testen (Unit-Test?)
* Integration-Tests (GraphQL Queries ausführen)
* End2End-Tests (GraphQL Queries per HTTP ausführen)

---
### Beispiel Resolver Test

* Mit Jest Testframework
* ```javascript
  it("ping resolver should work", () => {
    expect(resolvers.Query.ping({}, {}, {}, {})).toBe("hello");
  });
  ```

---
### Beispiel Integrationtest

* Der ApolloServer wird dabei mit den regulären Resolvern und dem echten Schema (oder Teilen davon) erzeugt
* Mit `executeOperation` am `ApolloServer` kann direkt ein Query ausgeführt werden
* Die Funktion liefert ein `GraphQLResponse` Objekt zurück
* Dieses Objekt hat ein `body`-Property:
  * das ist entweder ein einfaches Ergebnis (Normalfall)
  * oder ein "incremental" Result (z.B. für Queries mit `@defer`). Das ist noch experimentell.
* ```javascript
  const typeDefs = /* ... */;
  const resolvers = /* ... */;

const server = new ApolloServer({
    typeDefs,
    resolvers,
  });

it("ping should return hello", async () => {

const result = await server.executeOperation({
      query:"query { ping }"
    });

expect(result.body.singleResult.data?.ping).toBe(
      "hello"
    );
  });
  ```
---
### Tipp für JetBrains IDEs

* Wenn ihr IntelliJ oder Webstorm verwendet...
* ...könnt ihr das [GraphQL Plugin](https://plugins.jetbrains.com/plugin/8097-graphql) installieren
* dann könnt ihr im Source-Code mit `// language=GraphQL` markieren, wenn die nächste Zeile GraphQL Code enthält
* dann bekommt ihr Syntax Highlighting und bei Konfiguration des Schemas auch Code Completion
* ```javascript
  it("should return single story by id", async () => {
    const result = await server.executeOperation({

// language=GraphQL
      query: "query GetStory($storyId: ID!) { story(storyId: $storyId) { title } }",
    });
  });
  ```
---
### Beispiel Integrationtest

* Neben dem `query` können beim Ausführen auch Variablen übergeben
* Dazu das `variables`-Property verwenden
* ```javascript
  const server = /* ... */;

it("should return single story by id", async () => {
    const result = await server.executeOperation({

query:
        "query GetStory($storyId: ID!) { story(storyId: $storyId) { title } }",

variables: 
        { storyId: "1" },
    });

expect(result.body.singleResult.data?.story.title).toBe(
      "Authentication and Access Control with Relay"
    );
  });
  ```
---
### Beispiel Integrationtest: Context

* Die `executeOperation`-Funktion kann zwei Argumente entgegen nehmen:
  * `request` (wie gesehen Objekt mit `query` und evtl. `variables`)
  * `options`
* Über `options.contextValue` kann ein Context-Objekt für einen Request gesetzt werden  
  * Je mehr Informationen in den Resolvern über das Context-Objekt abgefragt werden, desto einfacher das Mocken an dieser Stelle...

* ```javascript
  it("should add new comment with user id from context", async () => {
    const result = await server.executeOperation({
        query: `mutation {
          addComment(input: { storyId: "3", content: "New Comment!"})	{
            ...on AddCommentSuccessPayload {
                newComment { id }
            }
          }
        }`
      },
      {
        contextValue: { userId: "U3" },
      }
    );

expect(result.body.singleResult.errors).toBeFalsy();
    expect(result.body.singleResult.data?.addComment.newComment.id).toBe("15");
  });
  ```

---
### Übung: Tests

* **Schreibe ein oder zwei einfache Tests für Queries**
* Die Datei `src/graphql/publy-api.test.ts` ist bereits vorbereitet
* Du musst dort den `ApolloServer` erzeugen und `typeDefs` und `resolvers` übergeben
* Schreibe dann ein oder zwei Tests um (einfache) Queries zu testen
* Du kannst die Tests mit `pnpm test` oder `pnpm test --watch` ausführen
* Hinweis: 
  * Da das eine TypeScript-Datei ist, werden eigentlichen Typen erwartet. Der einfachheithalber markiere `result` einfach als `any`
    * `const result: any = await server....`
  * Um Fehler zu sehen, am besten das Ergebnis mit `JSON.stringify(result)` auf der Konsole ausgeben
* Lösung in `steps/06-tests`
---
## TypeScript

*  Typen generieren
*  Resolver typisieren

---
### TypeScript
* Du kannst deine Resolver-Funktionen, den Context und einiges andere mit TypeScript Typen beschreiben
* Da viele Typ-Informationen schon im GraphQL-Schema vorhanden sind, kannst Du viele TypeScript Typen generieren lassen
* Dazu kannst Du den [graphql code generator](https://www.the-guild.dev/graphql/codegen) verwenden
* Der generiert dir dann unter anderem die Typen für deine Resolver
  * Achtung! Da die Verwendung der Resolver sehr flexibel ist, macht der Generator einige Kompromisse
  * Also nicht 100%ig darauf verlassen
* Den generierten Typen kannst Du beim erzeugen des resolvers-Objektes angeben:
  * ```javascript
    import { Resolvers } from "./generated/graphql-types";

export const resolvers: Resolvers = {
      Query: /* ... */
    }
    ```

---
### TypeScript: Context

* Auch für deinen Context kannst Du einen TypeScript-Typen erzeugen
* Diesen musst Du von Hand schreiben
* Den Typ gibst Du beim Erzeugen des `ApolloServer`-Objektes an
* ```typescript
  type PublyContext = {
    userId: string | null,
    dataSources: { userDataSource: UserDataSource }
  };

const server = new ApolloServer<PublyContext>({
    schema: /* ... */
  });
  ```
* Das `context`-Argument von den Resolvern ist dann korrekt typisiert

---
### TypeScript Beispiel
* Ein Beispiel der Publy-Anwendung mit TypeScript-Typen findest Du in `app/backend`

Geschafft! 😊

Vielen Dank für Eure Teilnahme!

Viel Spaß und Erfolg mit GraphQL!

Wenn ihr noch Fragen habt, könnt ihr mich erreichen:

nils@nilshartmann.net

https://nilshartmann.net

Xing

Twitter: @nilshartmann