Skip to content

Commit

Permalink
Documentation for 2.0.0 (#242)
Browse files Browse the repository at this point in the history
* Beginning of documentation for relationship properties

* Basic migration guide (navigation a little broken)

* Continued work on 2.0.0 docs

* Fixed headers not working for new pages (page keys cannot begin with a number)

* Remove node from where clause of connect

* A couple of outstanding documentation tasks

* Highlight that req must be passed into context, add lambda edge case

* Clarify Point and CartesianPoint usage in docs
  • Loading branch information
darrellwarde authored Jun 15, 2021
1 parent e207a02 commit aebace0
Show file tree
Hide file tree
Showing 15 changed files with 660 additions and 40 deletions.
2 changes: 2 additions & 0 deletions docs/antora/content-nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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[]
25 changes: 21 additions & 4 deletions docs/asciidoc/auth/setup.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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]
----
Expand All @@ -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.
Expand Down Expand Up @@ -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" }
}
}
}
]
) {
Expand Down
4 changes: 4 additions & 0 deletions docs/asciidoc/custom-resolvers.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
18 changes: 18 additions & 0 deletions docs/asciidoc/guides/2.0.0-migration/index.adoc
Original file line number Diff line number Diff line change
@@ -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
Loading

0 comments on commit aebace0

Please sign in to comment.