Documentation for 2.0.0

docs/antora/content-nav.adoc

@@ -44,4 +44,6 @@
 **** xref:guides/migration-guide/type-definitions/index.adoc[]
 **** xref:guides/migration-guide/queries/index.adoc[]
 **** xref:guides/migration-guide/mutations/index.adoc[]
+*** xref:guides/rel-migration/index.adoc[]
+**** xref:guides/rel-migration/mutations/index.adoc[]
 ** xref:troubleshooting/index.adoc[]

docs/asciidoc/auth/setup.adoc

@@ -22,14 +22,17 @@ Auth centric values on the Config object passed to Neo4jGraphQL or OGM.
 | Specify JWT secret
 
 |`noVerify`
-| Disable the verification of the JW
+| Disable the verification of the JWT
 
 |`rolesPath`
 | Specify where on the JWT the roles key is
 |===
 
 == Server Construction
-Request object needs to be injected into the context before you can use auth. Here is an example using Apollo Server;
+
+*An object key `req` or `request` must be passed into the context before you can use auth.* This object must contain request headers, including the authorization header containing the JWT for each request.
+
+Here is an example using Apollo Server:
 
 [source, javascript]
 ----
@@ -48,6 +51,16 @@ const server = new ApolloServer({
 });
 ----
 
+We expect there to be a `headers` key within either a `req` or `request` object in the context. If for example, you are using `apollo-server-lambda` to host a GraphQL API as a lambda function, the context function will have an `event` object which will need to be renamed to `req`. For example:
+
+[source, javascript]
+----
+const server = new ApolloServer({
+    schema: neoSchema.schema,
+    context: ({ event }) => ({ req: event }),
+});
+----
+
 == `rules`
 
 You can have many rules for many operations. We fall through each rule, on the corresponding operation, until we find a match. On no match found, an error is thrown. You can think of rules as a big OR.
@@ -83,8 +96,12 @@ mutation {
     createPosts(
         input: [
             {
-                content: "I like GraphQL",
-                creator: { connect: { where: { id: "user-01" } } }
+                content: "I like GraphQL"
+                creator: {
+                    connect: {
+                        where: { id: "user-01" }
+                    }
+                }
             }
         ]
     ) {

docs/asciidoc/custom-resolvers.adoc

@@ -3,6 +3,10 @@
 
 The library will autogenerate Query and Mutation resolvers, so you don’t need to implement those resolvers yourself. However, if you would like additional behaviours besides the autogenerated CRUD operations, you can specify custom resolvers for these scenarios.
 
+*A note on custom resolvers*
+
+> Due to the nature of the Cypher generation in this library, you must query any fields used in a custom resolver. For example, in the first example below calculating `fullName`, `firstName` and `lastName` must be included in the selection set whilst querying `fullName`. Without this being the case, `firstName` and `lastName` will be undefined in the custom resolver.
+
 == Custom object type field resolver
 
 If you would like to add a field to an object type which is resolved from existing values in the type, rather than storing new values, you should mark it with an <<type-definitions-access-control-ignore>> directive and define a custom resolver for it.

docs/asciidoc/guides/2.0.0-migration/index.adoc

@@ -0,0 +1,18 @@
+
+[[rel-migration]]
+= 2.0.0 Migration
+
+Version 2.0.0 of `@neo4j/graphql` adds support for relationship properties, with some breaking changes to facilitate these new features. All of the required changes will be on the client side, and this guide will walk through what has changed.
+
+== How to Upgrade
+
+Simply update `@neo4j/graphql` using npm or your package manager of choice:
+
+[source, bash]
+----
+npm update @neo4j/graphql
+----
+
+From this point on, it is primarily Mutations which will form the bulk of the migration:
+
+1. <<rel-migration-mutations>> for how you need to change your Mutations to work with the new schema