Update upgrading docs to refactoring

docs/en/02_Developer_Guides/19_GraphQL/07_tips_and_tricks.md

@@ -24,7 +24,7 @@ If you need the type name during normal execution of your app, e.g. to display i
 on the cached typenames, which are persisted alongside your generated schema code.
 
 ```php
-SchemaFactory::singleton()->get('default')->getTypeNameForClass($className);
+SchemaBuilder::singleton()->read('default')->getTypeNameForClass($className);
 ```
 
 ## Persisting queries

docs/en/02_Developer_Guides/19_GraphQL/08_upgrading.md

@@ -53,7 +53,8 @@ registration of types, execution of scaffolding, running queries and middleware,
 class has been broken up into separate concerns:
 
 * `Schema` <- register your stuff here
-* `QueryHandlerInterface` <- Handles GraphQL queries. You'll probably never have to touch it.
+* `QueryHandlerInterface` <- Handles GraphQL queries, applies middlewares and context.
+  You'll probably never have to touch it.
 
 ### Upgrading
 
@@ -72,7 +73,8 @@ SilverStripe\GraphQL\Manager:
 SilverStripe\GraphQL\Schema\Schema:
   schemas:
     default:
-      src: app/_graphql # A directory of your choice
+      src:
+        - app/_graphql # A directory of your choice
 ```
 
 Add the appropriate yaml files to the directory. For more information on this pattern, see
@@ -142,7 +144,7 @@ and moved into a class.
 
 ### Upgrading
 
-Move your resolvers into one or many `ResolverProvider` implementations, register them.
+Move your resolvers into one or many classes, and register them.
 
 **before**
 ```php
@@ -156,15 +158,16 @@ class LatestPostResolver implements OperationResolver
 ```
 
 **after**
+
+**app/_graphql/config.yml**
 ```yaml
-SilverStripe\Core\Injector\Injector:
+resolvers:
-  SilverStripe\GraphQL\Schema\Registry\ResolverRegistry:
+  - MyProject\Resolvers\MyResolverA
-    constructor:
+  - MyProject\Resolvers\MyResolverB
-      myResolver: '%$MyProject\Resolvers\MyResolvers'
 ```
 
 ```php
-class MyResolvers extends DefaultResolverProvider
+class MyResolverA
 {
     public static function resolveLatestPost($object, array $args, $context, ResolveInfo $info)
     {
@@ -218,7 +221,7 @@ class MyProvider implements ScaffoldingProvider
 SilverStripe\GraphQL\Schema\Schema:
   schemas:
     default:
-      builders:
+      execute:
         - 'MyProject\MyProvider'
 ```
 
@@ -246,7 +249,7 @@ A model type is just a type that is backed by a class that express awareness of
 At a high-level, it needs to answer questions like:
 
 * Do you have field X?
-What type is field Y?
+  What type is field Y?
 * What are all the fields you offer?
 * What operations do you provide?
 * Do you require any extra types to be added to the schema?
@@ -304,14 +307,33 @@ Change the casing in your queries.
 **before**
 ```graphql
 query readPages {
+  edges {
     nodes {
      Title
      ShowInMenus
     }
+  }
 }
 ```
 
 **after**
+```graphql
+query readPages {
+  edges {
+    node {
+      title
+      showInMenus
+    }
+  }
+}
+```
+
+### `edges` no longer required
+
+We don't have [cursor-based pagination](https://graphql.org/learn/pagination/) in Silverstripe CMS, so
+the use of `edges` is merely for convention. You can eliminate a layer here and just use `nodes`, but `edges`
+still exists for backward compatibility.
+
 ```graphql
 query readPages {
   nodes {
@@ -321,6 +343,7 @@ query readPages {
 }
 ```
 
+
 ## DataObject type names are simpler
 
 To avoid naming collisions, the 3.x release of the module used a pretty aggressive approach to ensuring
@@ -398,10 +421,3 @@ Status:
   CANCELLED: Cancelled
   PENDING: Pending
 ```
-
-## Middleware signature is more loosely typed
-
-In the 3.x release, `QueryMiddleware` was a very specific implementation that took parameters that were unique
-to queries. The middleware pattern is now more generic and accepts a loosely-typed `params` array that can consist
-of anything -- more like an `event` parameter for an event handler. If you've defined custom middleware, you'll
-need to update it. Check out the [adding middleware](extending/adding_middleware) section for more information.