Instructor: We'll start out by partially populating our graph with planet and person nodes, using some data from Swappy that we can reference by parameter. Now that we've got a running, populated graph, all we need is an API to allow us to access it.
Here's a little bit of boilerplate to get an Apollo GraphQL server up. There's nothing out of the ordinary here, other than the driver we're passing into the context, which we are creating from the Neo4j driver module to connect to our running instance.
We can fill in our typedefs with some high-level information about the two node types we've put into the graph. Let's only go as far as the name property for right now and expose those two types in the query.
Now that we've got all of our basic structures in place, let's spin up the API and head over to the playground to see what we can see. Let's start by getting a list of all of our people and planets.
Oh no, we forgot to build our resolvers. Not to worry, let's see what the neo4j-graphql-js module can do for us. We can add the module and destructure its augmentSchema function to add a little magic to our type definitions.
Let's get that running again and head back to the playground. Our first surprise will be in running that query again. neo4j-graphql-js seems to have implemented our resolvers for us -- what a pal. If we take a look back at the debug output for our running API, we can even see that the augmented schemas have translated the resolution process into Cypher queries to run against Neo4j.
We've got one more surprise in the schema tab, where we can see we've got a few extra goodies waiting for us. Not only have those augmented queries that we wrote gained a few default parameters, but we've also got a pair of mutations for each of our node types.
At this point, we can even go so far as to delete the queries that we specified and just let neo4j-graphql-js do the lifting for us. We can even replace Apollo's makeExecutableSchema function with a bespoke makeAugmentedSchema function and get the same results.