Apply suggestions from code review

Co-authored-by: Michael Webb <28074382+mjfwebb@users.noreply.github.com>
Co-authored-by: Lidia Zuin <102308961+lidiazuin@users.noreply.github.com>

Author: 3 people

modules/ROOT/pages/directives/database-mapping.adoc

@@ -12,7 +12,28 @@ Each type in your GraphQL type definitions can be mapped to an entity in your Ne
 
 === Definition
 
-// tba
+[source, graphql, indent=0]
+----
+"""
+Instructs @neo4j/graphql to treat this field as a relationship. Opens up the ability to create and connect on this field.
+"""
+directive @relationship(
+  type: String!
+  """Valid and default directions for this relationship."""
+  queryDirection: RelationshipQueryDirection = DEFAULT_DIRECTED
+  direction: RelationshipDirection!
+  """
+  The name of the interface containing the properties for this relationship.
+  """
+  properties: String
+  """
+  Prevent all but these operations from being generated for this relationship
+  """
+  nestedOperations: [RelationshipNestedOperations!]! = [CREATE, UPDATE, DELETE, CONNECT, DISCONNECT, CONNECT_OR_CREATE]
+  """Prevent aggregation for this relationship"""
+  aggregate: Boolean = true
+) on FIELD_DEFINITION
+----
 
 === Usage
 
@@ -37,11 +58,11 @@ type Actor {
 [NOTE]
 ====
 The `@relationship` directive is used twice, once on each end of the relationship.
-This is the standard way of modeling a relationship with the GraphQL library.
-However, it is not a requirement of the type definitions themselves and relationships can deliberately be underspecified, for example to limit access through the API layer.
+This is the standard way of modeling a relationship with the GraphQL Library.
+However, it is not a requirement of the type definitions themselves as relationships can deliberately be underspecified, for example to limit access through the API layer.
 ====
 
- Also see xref::/directives/schema-configuration/field-configuration/#_relationship[`@relationship` field configuration].
+See also: xref::/directives/schema-configuration/field-configuration/#_relationship[`@relationship` field configuration].
 
 == `@relationshipProperties`
 
@@ -86,7 +107,14 @@ For more information, see xref::/types/relationships.adoc[Type definitions -> Re
 
 === Definition
 
-// tba
+[source, graphql, indent=0]
+----
+"""Informs @neo4j/graphql of node metadata"""
+directive @node(
+  """The labels to map this GraphQL type to in the Neo4j database"""
+  labels: [String!]
+) on OBJECT
+----
 
 === Usage
 
@@ -254,7 +282,16 @@ await startStandaloneServer(server, {
 
 === Definition
 
-// tba
+[source, graphql, indent=0]
+----
+"""
+Instructs @neo4j/graphql to map a GraphQL field to a Neo4j node or relationship property.
+"""
+directive @alias(
+  """The name of the Neo4j property"""
+  property: String!
+) on FIELD_DEFINITION
+----
 
 === Usage
 

modules/ROOT/pages/directives/indexes-and-constraints.adoc

@@ -170,7 +170,8 @@ query {
 
 === Definition
 
-Unique node property constraints map to `@unique` directives used in your type definitions, which has the following definition:
+Unique node property constraints map to `@unique` directives used in your type definitions.
+They have the following definition:
 
 [source, graphql, indent=0]
 ----
@@ -181,8 +182,9 @@ directive @unique(
 ) on FIELD_DEFINITION
 ----
 
-Using this directive does not automatically ensure the existence of these constraints, and you will need to run a function on server startup. 
-See the section xref::/directives/indexes-and-constraints.adoc#_asserting_constraints[Asserting constraints] for details.
+Using this directive does not automatically ensure the existence of these constraints.
+Run a function on server startup.
+See section xref::/directives/indexes-and-constraints.adoc#_asserting_constraints[Asserting constraints] for details.
 
 === Usage
 

modules/ROOT/pages/directives/schema-configuration/type-configuration.adoc

@@ -188,7 +188,16 @@ type SomeType {
 
 === Definition
 
-// tba
+[source, graphql, indent=0]
+----
+"""
+Instructs @neo4j/graphql to use the given value as the plural of the type name
+"""
+directive @plural(
+  """The value to use as the plural of the type name."""
+  value: String!
+) on OBJECT | INTERFACE | UNION
+----
 
 === Usage
 

modules/ROOT/pages/security/authorization.adoc

@@ -7,7 +7,7 @@ They use predicates to evaluate the data accessed by the Cypher generated from a
 
 All authorization rules have an implied requirement for authentication, given that the rules are normally evaluated against values in the JWT payload.
 
-In the case of explicit authentication, configured using the xref::/security/authentication.adoc#_authentication[`@authentication`] directive, it is only ever evaluated during Cypher translation time.
+In the case of explicit authentication, configured using the xref::/security/authentication.adoc#_authentication[`@authentication`] directive, it is only evaluated during Cypher translation time.
 Unauthenticated requests with queries requiring authentication never reach the database.
 
 == `@authorization`

modules/ROOT/pages/security/configuration.adoc

@@ -150,7 +150,13 @@ Filtering can be configured for additional JWT claims using the `@jwt` directive
 
 ==== Definition
 
-// tba
+[source, graphql, indent=0]
+----
+"""
+Instructs @neo4j/graphql that the flagged object represents the relevant JWT payload
+"""
+directive @jwt on OBJECT
+----
 
 ==== Usage
 
@@ -173,7 +179,18 @@ You can use any name as long as it is decorated with the `@jwt` directive.
 
 ==== Definition
 
-// tba
+[source, graphql, indent=0]
+----
+"""
+Instructs @neo4j/graphql that the flagged field has a mapped path within the JWT Payload.
+"""
+directive @jwtClaim(
+  """
+  The path of the field in the real JWT as mapped within the JWT Payload.
+  """
+  path: String!
+) on FIELD_DEFINITION
+----
 
 ==== Usage
 

modules/ROOT/pages/security/subscriptions-authorization.adoc

@@ -6,7 +6,8 @@ Subscriptions require their own authorization rules, which are configured with t
 
 == `@subscriptionsAuthorization`
 
-Rules for subscriptions authorization are different to normal authorization rules because only filtering rules are available for subscriptions events and subscriptions events have more limitations in how they can be filtered.
+Rules for subscriptions authorization are different to normal authorization rules.
+Only filtering rules are available for subscriptions events and there are more limitations in how they can be filtered.
 
 All subscriptions authorization rules have an implied requirement for authentication, given that the rules are normally evaluated against values in the JWT payload.