131 lines
4.0 KiB
Markdown
131 lines
4.0 KiB
Markdown
---
|
|
title: "Dgraph - Part 2: GraphQL, Schema & first steps"
|
|
date: 2020-03-24
|
|
draft: false
|
|
tags: ["database","graphql","grpc","graph"]
|
|
archive: ["Dgraph Basics"]
|
|
categories: ["Archive"]
|
|
---
|
|
Last time we started the server and saved our first data. For this we used Dgraph's Ratel Interface. We also provided a GraphQl endpoint. Here we create the same data and connections as before in Ratel.
|
|
At the moment we cannot do anything with our GraphQL endpoint because GraphQL needs a schema. For this we create a file called schema.graphql:
|
|
```graphql
|
|
type Person {
|
|
name: String! @id
|
|
hometown: String
|
|
friend_of: [Person]
|
|
}
|
|
```
|
|
The structure is the same as in part 1. In addition, we define the field name as a mandatory field and ensure that the entries are unique. We achieve this with the directive @i. You could of course also specify an additional field with a unique ID, but for our example this should be enough for now.
|
|
The field friend_of is defined as a list of the type person. This means that Dgraph will create a connection to another person.
|
|
Now we can send our schema to the admin endpoint:
|
|
```sh
|
|
curl -X POST localhost:8080/admin/schema -d '@schema.graphql'
|
|
```
|
|
Dgraph has added significantly more complexity to our schema. If we look at the schema using a GraphQL client, we see the following additions:
|
|
- predefined mutation for creating, changing or deleting people
|
|
- predefined queries for retrieving people
|
|
- Different input types for filtering and sorting, as well as pagination
|
|
|
|
## Store the first records
|
|
|
|
Now that we've submitted the schema, we can interact with the GraphQL endpoint. Compared to the RDF N-Quads from Part 1, adding the same people looks a bit more complex.
|
|
In addition, the links via friendof can only be partially set directly when they are created. We can use Harry Osborne to create the other two people as part of the friend_of connection, but we still have to update Mary Jane Watson afterwards.
|
|
When we use Mary Jane Watson to create our Peter Parker as part of the friend_of connection Peter Parker would exist twice in the database.
|
|
```graphql
|
|
mutation addPerson {
|
|
addPerson(input:[
|
|
{
|
|
name: "Harry Osborne",
|
|
hometown: "New York",
|
|
friend_of: [
|
|
{
|
|
name: "Mary Jane Watson",
|
|
hometown: "New York",
|
|
},
|
|
{
|
|
name: "Peter Parker",
|
|
hometown: "New York",
|
|
},
|
|
|
|
]
|
|
}
|
|
])
|
|
{
|
|
person{
|
|
name
|
|
}
|
|
},
|
|
updatePerson(input:
|
|
{
|
|
filter: {name: {eq: "Mary Jane Watson"}}
|
|
set: {friend_of: [{name: "Peter Parker"}]}
|
|
},
|
|
){
|
|
person{
|
|
name
|
|
friend_of{
|
|
name
|
|
}
|
|
}
|
|
}
|
|
}
|
|
```
|
|
A note about the updatePerson mutation: In this example, we simply added the updatePerson mutation to the addPerson mutation. If we tried to add another updatePerson mutation, GraphQL would report an error:
|
|
Fields updatePerson conflict because they have differing arguments. Use different aliases on the fields to fetch both if this was intentional.
|
|
|
|
If we work with Aliases in lines 21 and 34, there is no problem.
|
|
```graphql
|
|
mutation addPerson {
|
|
addPerson(input:[
|
|
{
|
|
name: "Harry Osborne",
|
|
hometown: "New York",
|
|
},
|
|
{
|
|
name: "Peter Parker",
|
|
hometown: "New York",
|
|
},
|
|
{
|
|
name: "Mary Jane Watson",
|
|
hometown: "New York",
|
|
},
|
|
])
|
|
{
|
|
person{
|
|
name
|
|
}
|
|
},
|
|
mary: updatePerson(input:
|
|
{
|
|
filter: {name: {eq: "Mary Jane Watson"}}
|
|
set: {friend_of: [{name: "Peter Parker"}]}
|
|
},
|
|
){
|
|
person{
|
|
name
|
|
friend_of{
|
|
name
|
|
}
|
|
}
|
|
},
|
|
harry: updatePerson(input:
|
|
{
|
|
filter: {name: {eq: "Harry Osborne"}}
|
|
set: {friend_of: [
|
|
{name: "Mary Jane Watson"},
|
|
{name: "Peter Parker"}
|
|
]}
|
|
},
|
|
){
|
|
person{
|
|
name
|
|
friend_of{
|
|
name
|
|
}
|
|
}
|
|
}
|
|
}
|
|
```
|
|
As you can see, with Dgraph you can start using GraphQL quite quickly. Dgraph creates the CRUD functionality for you. You do not need to write resolvers or anything.
|
|
Next time we will take a closer look at the RDF N-Quads
|