Dgraph - Part 2: GraphQL, Schema & first steps

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:

1
2
3
4
5

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:

1

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

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