DEV Community: verneleem

GraphQL RBAC without JWT Roles

verneleem — Mon, 03 Jan 2022 05:12:02 +0000

Before I continue from my last post GraphQL Auth Without Middleware, a question came up:

Is it possible to use Role Based Access Control (RBAC) in Dgraph Authorization rules, when my authentication and JWT provider is not capable of putting roles into the JWT given to clients?

Yes, this is possible. Before I give a brief work around to enable this with a full example, I want to first show another reason why someone might want to not put user roles into the JWT.

If you are familiar with JWTs, you will know that a JWT is secure only in that it is signed with a private key. This signature on the JWT validates that the payload is authenticated, but it does not prevent anyone else from decoding the payload. It does prevent JWT modification without access to the signing private key. The kicker though is that under most implementation you cannot revoke JWT tokens once issued.

Once issued, access tokens and ID tokens cannot be revoked in the same way as cookies with session IDs for server-side sessions.

As a result, tokens should be issued for relatively short periods, and then refreshed periodically if the user remains active.

—Auth0 Docs

So then let's play out a situation: A admin comes to the sight and is issued a JWT with a role of admin giving him full control. Even if this JWT is only short lived 24 hours, let's say this specific JWT is compromised is some way. Now how do you handle this?

Do you change the private key which would also invalidate ALL of the other users tokens?
Do you change all of your auth rules to use a new role and trash that old role?

Remember time is ticking and you have a hacker out there with a full access token. You want to block them NOW, but you cannot just stop your service for all other users.

There really isn't a good solution. There are some other hack around solutions such as How do I revoke JWT everytime a new token is geneated using django-graphql, but nothing that works really well because a user may actually want to be signed into multiple devices at the same time, and this hack around would prevent that from being allowed.

So my solution is: never put the role into the JWT.

How then can you use a role in my auth rules if it is not in the JWT? You just need to create a path between all of your data needing RBAC to all of your users and put their role in the database. By keeping the role in the db instead of the JWT you can grant/revoke access without the user needing to reauthenticate and without the need to revoke compromised JWTs.

Linking all types needing RBAC to all your users sounds like a daunting task, but let me show you how easy it is.

Let's start with three types: User, Pages, Comments. To set this linking up, we will add a 4th type Link that will be this linking node.

type User {
  username: String! @id
  comments: [Comment]
  link: Link!
}
type Page {
  id: ID
  title: String! @search
  content: String
  comments: [Comment]
  link: Link!
}
type Comment {
  id: ID
  comment: String! @search
  by: User!
  for: Page! @hasInverse(field: "comments")
  link: Link!
}
type Link {
  id: String! @id
  users: [Link] @hasInverse(field: "link")
}

Purposefully, the Link id is of type String instead of ID and it has the @id directive. This will make it a unique string id to help us create something we can easily reference later on.

After deploying this GraphQL schema to Dgraph, we need to create a single node for this linking node and then lock it down so no new nodes for this type will be created later. We can create a node by using the addLink mutation:

mutation {
  addLink(input: [{id: "link"}]) {
    link {
      id
    }
  }
}

Very simply this created a single Link node with the id equal to "link". If you go back up and look at the schema, you will notice that every type links to the type Link through the field link, but the link node only has a field connecting it inversely back to users. Also by making the link field a required field, every user, page, and comment must have a link. We want all of them to use the same link. So the next step is going to disable any future links from being created by the GraphQL endpoint. We do this by first disabling the mutations to add, update, and delete links, and then we create an auth rule on the Link type that will always be false, in essence never allowing a parent to create a new child link, but forcing it to use the existing link already created. We don't want to expose the root level queries for the Link type either, so we will also disable those from being generated by Dgraph.

type User {
  id: ID!
  username: String! @id
  comments: [Comment]
  link: Link!
}
type Page {
  id: ID
  title: String! @search
  content: String
  comments: [Comment]
  link: Link!
}
type Comment {
  id: ID
  comment: String! @search
  by: User!
  for: Page! @hasInverse(field: "comments")
  link: Link!
}
type Link @generate(
  query: {
    get: false,
    query: false,
    aggregate: false
  },
  mutation: {
    add: false,
    update: false,
    delete: false
  }
) @auth(
  add: { rule: "{$ALWAYS: { eq: \"_NEVER_\" }}" },
  update: { rule: "{$ALWAYS: { eq: \"_NEVER_\" }}" },
  delete: { rule: "{$ALWAYS: { eq: \"_NEVER_\" }}" }
) {
  id: String! @id
  users: [Link] @hasInverse(field: "link")
}

Deploying this GraphQL schema to Dgraph (after following the steps above) will leave us with a single Link node that is immutable. The auth rules {$ALWAYS: { eq: \"_NEVER_\" }} is a trick I use that makes the schema rules easy to read, and should always equate to false as long as the JWT does not contain a claim for ALWAYS: "_NEVER_" which should not be there unless you specifically craft it that way by your authentication jwt generator.

Now that we have this in place, we can start adding users, pages, and comments. Here are a few mutations to get you started:

mutation addFooBar {
  addUser(input: [
    { username: "foo", link: { id: "link" } },
    { username: "bar", link: { id: "link" } }
  ]) {
    user {
      id
      username
    }
  }
}
mutation addNewPageWithComments {
  addPage(input: [
    {
      title: "Dgraph makes GraphQL Easy",
      content: "Did you know you can do role-less RBAC with Dgraph GraphQL?",
      link: { id: "link" },
      comments: [
        {
          comment: "I never thought this would be possible!",
          by: { username: "bar" },
          link: { id: "link" }
        }, {
          comment: "This has made my life so much easier.",
          by: { username: "foo" },
          link: { id: "link" }
        }
      ] },
  ]) {
    page {
      id
      title
      content
      comments {
        id
        comment
        by {
          id
          username
        }
      }
    }
  }
}

Now that we have a GraphQL API with our singular link node, 2 users, 1 page, and 2 comments, let's add user roles and auth rules to do the following:

Only let an Editor edit pages.
Only let an Admin delete pages.
Let an Admin delete any comment.
Let a user delete their own comment.
Only let a Subscriber add a new comment.


type User {
  id: ID!
  username: String! @id
  roles: [Role] @search
  comments: [Comment]
  link: Link!
}
enum Role {
  Admin
  Editor
  Author
  Subscriber
  Disabled
}
type Page @auth(
  # Only let an Editor edit pages
  update: { rule: """
    query ($username: String!) {
      queryPage {
        link {
          users(filter: {
            username: { eq: $username },
            roles: { eq: Editor }
          }) {
            id
          }
        }
      }
    }
  """ },
  # Only let an Admin delete pages
  delete: { rule: """
    query ($username: String!) {
      queryPage {
        link {
          users(filter: {
            username: { eq: $username },
            roles: { eq: Admin }
          }) {
            id
          }
        }
      }
    }
  """ }
) {
  id: ID
  title: String! @search
  content: String
  comments: [Comment]
  link: Link!
}
type Comment @auth(
  delete: { OR: [
    # Let an Admin delete any comment
    { rule: """
      query ($username: String!) {
        queryComment {
          link {
            users(filter: {
              username: { eq: $username },
              roles: { eq: Admin }
            }) {
              id
            }
          }
        }
      }
    """ },
    # Let a user delete their own comment
    { rule: """
      query ($username: String!) {
        queryComment {
          by(filter: {
            username: { eq: $username },
          }) {
            id
          }
        }
      }
    """ },
  ] },
  add: { rule: """
    query ($username: String!) {
      queryComment {
        link {
          users(filter: {
            username: { eq: $username },
            roles: { eq: Subscriber }
          }) {
            id
          }
        }
      }
    }
  """ }
) {
  id: ID
  comment: String! @search
  by: User!
  for: Page! @hasInverse(field: "comments")
  link: Link!
}
type Link @generate(
  query: {
    get: false,
    query: false,
    aggregate: false
  },
  mutation: {
    add: false,
    update: false,
    delete: false
  }
) @auth(
  add: { rule: "{$ALWAYS: { eq: \"_NEVER_\" }}" },
  update: { rule: "{$ALWAYS: { eq: \"_NEVER_\" }}" },
  delete: { rule: "{$ALWAYS: { eq: \"_NEVER_\" }}" }
) {
  id: String! @id
  users: [Link] @hasInverse(field: "link")
}
# Dgraph.Authorization {"VerificationKey":"your-256-bit-secret","Header":"X-My-App-Auth","Namespace":"https://dev.to/verneleem/example","Algo":"HS256"}

You will need to setup an authentication service to generate JWTs for your users with their username in the claim. See Dgraph Docs for more information. To aide in this process we created some JWTs you can use below.

This new schema with auth rules covers just the rules listed above. You will want to flesh out this schema with more rules to meet your own rule set for your application needs.

After deploying this GraphQL schema to Dgraph GraphQL, you will mostly likely want to add some roles to users. Here are a few mutation blocks to help do this:

mutation makeFooSubscriber {
  updateUser(input: {
    filter: {
      username: { eq: "foo" }
    }
    set: {
      roles: [Subscriber]
    }
  }) {
    user {
      id
      username
      roles
    }
  }
}
mutation makeBarEditor {
  updateUser(input: {
    filter: {
      username: { eq: "bar" }
    }
    set: {
      roles: [Editor]
    }
  }) {
    user {
      id
      username
      roles
    }
  }
}
mutation addBazAdmin {
  addUser(input: [{
    username: "baz",
    roles: [Admin],
    link: { id: "link" }
  }]) {
    user {
      id
      username
      roles
    }
  }
}

After making the mutations adding roles to your users and adding the new user baz, you can then use the correlating JWTs below sending them in the header of the GraphQL request in the X-My-App-Auth key.

foo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NDExNjgwMDAsImV4cCI6NDEwMjQ0NDgwMCwiaXNzIjoiand0LmlvIiwiaHR0cHM6Ly9kZXYudG8vdmVybmVsZWVtL2V4YW1wbGUiOnsidXNlcm5hbWUiOiJmb28ifX0.zoCgwCRKGATrL_9sw180Xb1X2PnsH-y62AuTeKKQ5MU
bar: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NDExNjgwMDAsImV4cCI6NDEwMjQ0NDgwMCwiaXNzIjoiand0LmlvIiwiaHR0cHM6Ly9kZXYudG8vdmVybmVsZWVtL2V4YW1wbGUiOnsidXNlcm5hbWUiOiJiYXIifX0.Vk_ihPY-QZfAjD5r5HB4Z8T9aaCoO9bPYV3aU5XCx5c
baz: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NDExNjgwMDAsImV4cCI6NDEwMjQ0NDgwMCwiaXNzIjoiand0LmlvIiwiaHR0cHM6Ly9kZXYudG8vdmVybmVsZWVtL2V4YW1wbGUiOnsidXNlcm5hbWUiOiJiYXoifX0.W4A_QDJyqeir7FZgHCkJLadoPI__-ZMIDpo2yQb9q4c

Pick one of these JWTs and try to do the following tasks

Add a new Comment
Delete all comments
Delete a Page
Edit a Page

Hope this helps you see how you can accomplish the feat of Role Based Access Control without sacrificing your roles into your tokens.

What is great about this, is that is you update a user's role you can use the same token above and it will immediately resolve the rules for their new role. No longer will you have to force users to sign out and sign back in to grant additional roles. Also the best benefit in terms of security, is that if a user becomes compromised, you can immediately revoke the role for that specific user without waiting for them to destroying their token or even worse invalidating all users tokens to make the application secure.

Photo by Clay Banks on Unsplash

GraphQL Auth without Middleware

verneleem — Thu, 18 Nov 2021 04:04:55 +0000

What if I told you, that you could have one of the most advanced auth built into your GraphQL API without adding any middleware?

Before we begin though, let's break apart Auth into its two sub-categories, Authentication and Authorization. Authentication is "who you are" while Authorization is "what you are allowed" to do. For this short article, we will be covering the latter of these two concepts.

Since GraphQL is a stateless API, it does not create sessions between the client and the API. The common method to authorize clients to query or mutate data is by passing a token known as a JSON Web token (JWT). The common way for a client to obtain a JWT is by authenticating through some auth provider who returns a JWT to the client. This JWT then provided by the client to the GraphQL API in the request is used in the GraphQL API to authorize actions to perform create, read, update, and delete (CRUD) operations on data.

In almost every GraphQL API, GraphQL developers need to add middleware to create rules for the authorization of these CRUD actions. There is on implementation of GraphQL however that stands above the competition, Dgraph! Dgraph has engineered their GraphQL API which is embedded into the core of the database to generate CRUD operations with authorization built-in. How is this possible? When a developer deploys a schema, they simply need to create rules using the @auth directive. Dgraph will then apply these rules and run them as a single query operation (avoiding the N+1 problem) when querying and mutating data.

Let's think of some rules that we would want in place in our API continuing with the example in the previous post, A Backend with Flexibility, with three types: User, Pet, and Breed.

Only users with an admin role OR a special system account should be allowed to create new users.
Only users with an admin role should be allowed to update or delete users.
Users should only be allowed to see themselves, friends, and friends of friends.
Users can set their profile to public.
Only pets can be added that you own
Users can only update pets that they own
Users can only delete pets that they own
Users can only see their own pets or pets of their friends
Breeds can only be created, updated, and deleted by users with an admin role.
Anybody can read breeds.

Three of these rules (#1, #2, and #9) are simple Role Based Access Control (RBAC) rules. The rest of these rules, get more complicated into what is known as Attribute Based Access Control (ABAC) rules. And some of these can seem even more complex (#3 & #8) that they fall into a different category of rules I would call Graph Based Access Control (GBAC) rules.

To help you better understand how these rules will work, here is a sample JWT and decoded payload from an authenticated user signed with the key super-secret:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjQxMDI0NjYzOTksInN1YiI6InZlcm5lbGVlbSIsIm5hbWUiOiJ2ZXJuZWxlZW0iLCJpYXQiOjE2MzY4NjU3OTYsImlzcyI6Imp3dC5pbyIsImh0dHBzOi8vZGV2LnRvL3Zlcm5lbGVlbSI6eyJyb2xlIjoiYWRtaW4iLCJ1c2VybmFtZSI6InZlcm5lbGVlbSJ9fQ.S3Alqp8y_qFVibFvuVWyFR8Ybg26ksvWSwyWIE22W5w

{
  "exp": 4102466399,
  "sub": "verneleem",
  "name": "verneleem",
  "iat": 1636865796,
  "iss": "jwt.io",
  "https://dev.to/verneleem":{
    "role":"admin",
    "username":"verneleem"
  }
}

Note: JWTs payloads are not natively encrypted. They are only secure by the signing secret. This makes it important to keep the secret used to sign and validate signed JWTs a secret and not easily guessable. DO not use something like super-secret as the secret for your JWT signing provider. This then also shows the importance of keeping sensitive private user data out of your JWT payload. JWTs for the most part should not contain emails, and should definitely not contain the authenticated user's password!

When you look at the payload above, you will see JSON Object keys. These keys are called claims. Some of these claims are standard claims such as the expiration (exp) and issued at (iat) timestamps of the token, but we can use the claims in the custom claim https://dev.to/verneleem for the rules in our API. This custom claim need not be a URI, but needs to be something unique that does not conflict with standard claims or any other custom claims your JWT provider may be issuing. You can refer to the Dgraph Authorization Docs to see how to provide this custom claim, a.k.a. namespace, to Dgraph.

So we have access to two identifications for the user from the JWT claims: role and username. We will use these in our rules as $role and $username.

For the RBAC rules we can write them as:

{$role:{eq:"admin"}}
{$role:{eq:"system"}}

This rule #1 would pass for the given JWT because the role is equal to "admin". However rule #2 would be denied because the role is not equal to "system" for the given JWT.

To put these rules together we can use logical combinators. Let's flesh out rules #1, #2, and #9 using what we know so far with RBAC rules.

type User @auth(
  add: {
    OR: [
      { rule: "{$role:{eq:\"admin\"}}" }
      { rule: "{$role:{eq:\"system\"}}" }
    ]
  }
  update: { rule: "{$role:{eq:\"admin\"}}" }
  delete: { rule: "{$role:{eq:\"admin\"}}" }
) {
  id: ID!
  name: String! @search
  friends: [User] @hasInverse(field: "friends")
  pets: [Pet]
}
type Pet {
  id: ID!
  name: String! @search
  breed: Breed!
  owner: User! @hasInverse(field: "pets")
}
type Breed @auth(
  add: { rule: "{$role:{eq:\"admin\"}}" }
  update: { rule: "{$role:{eq:\"admin\"}}" }
  delete: { rule: "{$role:{eq:\"admin\"}}" }
) {
  name: String! @id
  pets: [Pet] @hasInverse(field: "breed")
}

If we stopped right there and deployed this schema in Dgraph, we would have a fully functioning GraphQL API with Authorization that obeys these RBAC rules we defined in these two types.

Moving on to more complex rules, let's look at ABAC rules. These rules look at attributes of the data to grant access to only specific data nodes.

The best part that makes ABAC rules easy to use, is that these rules are written using plain GraphQL queries. Yes! You read that right. Write a rule for the GraphQL API that itself, the rule, is a GraphQL query.

Rules #5, #6, and #7 all use the owner attribute of each pet to determine if the client should be granted access to perform the specific action. The query to find this is simply:

query ($username: String!) {
  queryPet {
    owner(filter:{name:{eq:$username}}) {
      id
    }
  }
}

Rule # 4 uses a field of the user to see if they have made their profile public. We will need to add the isPublic field and then we can use this GraphQL query rule:

query {
  queryUser(filter:{isPublic:true}) {
    id
  }
}

Now putting this rule in our schema makes it as follows:

type User @auth(
  add: {
    OR: [
      { rule: "{$role:{eq:\"admin\"}}" }
      { rule: "{$role:{eq:\"system\"}}" }
    ]
  }
  update: { rule: "{$role:{eq:\"admin\"}}" }
  delete: { rule: "{$role:{eq:\"admin\"}}" }
  query: { rule: "query { queryUser(filter:{isPublic:true}) { id } }" }
) {
  id: ID!
  name: String! @search
  friends: [User] @hasInverse(field: "friends")
  pets: [Pet]
  isPublic: Boolean @search
}
type Pet @auth(
  add: { rule: "query($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}}}" }
  update: { rule: "query($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}}}" }
  delete: { rule: "query($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}}}" }
) {
  id: ID!
  name: String! @search
  breed: Breed!
  owner: User! @hasInverse(field: "pets")
}
type Breed @auth(
  add: { rule: "{$role:{eq:\"admin\"}}" }
  update: { rule: "{$role:{eq:\"admin\"}}" }
  delete: { rule: "{$role:{eq:\"admin\"}}" }
) {
  name: String! @id
  pets: [Pet] @hasInverse(field: "breed")
}

Now here is where it starts to get fun. Looking again at rules #3 and #8, you will see that they are more complex, and do not depend on just a single level down into the graph, but actually multiple levels down:

Rule #3. Users should only be allowed to see themselves, friends, and friends of friends.
Rule #8. Users can only see their own pets or pets of their friends.

To make rule #3 you will need to break it down into three pieces. The first piece is Users should be allowed to see themselves. Here is the query for this piece:

query ($username:String!) {
  queryUser(filter:{name:{eq:$username}}) {
    id
  }
}

And then for the next piece, you need to query to see if the user is your friend. Here is the query for this next piece:

query ($username:String!) {
  queryUser {
    friends(filter:{name:{eq:$username}}) {
      id
    }
  }
}

And then traversing down the graph one step further, this next query will find all root nodes who are friends of friends:

query ($username:String!) {
  queryUser {
    friends {
      friends(filter:{name:{eq:$username}}) {
        id
      }
    }
  }
}

If we put all three of these pieces together we can write a set of rules that does an advanced Graph Based Access Control rule to grant access to data based upon the graph of data we are trying to access.

Taking this idea further for just a minute, imagine how this might be used to perform graph based access control that not only uses the graph of data to grant access but also your own relationship within that graph. If you want to follow this theory through then check out Putting it All Together - Dgraph Authentication, Authorization, and Granular Access Control Getting back to the schema and auth rules we have been working through let's add the above rule set and a rule to grant query access to user's own pets and their friends pets too.


type User @auth(
  add: {
    OR: [
      { rule: "{$role:{eq:\"admin\"}}" }
      { rule: "{$role:{eq:\"system\"}}" }
    ]
  }
  update: { rule: "{$role:{eq:\"admin\"}}" }
  delete: { rule: "{$role:{eq:\"admin\"}}" }
  query: { OR: [
    {rule: "query { queryUser(filter:{isPublic:true}) { id } }" }
    {rule: "query ($username:String!) { queryUser(filter:{name:{eq:$username}}) { id } }"}
    {rule: "query ($username:String!) { queryUser { friends(filter:{name:{eq:$username}}) { id } } }"}
    {rule: "query ($username:String!) { queryUser { friends { friends(filter:{name:{eq:$username}}) { id } } } }"}
  ]}
) {
  id: ID!
  name: String! @search
  friends: [User] @hasInverse(field: "friends")
  pets: [Pet]
  isPublic: Boolean @search
}
type Pet @auth(
  add: { rule: "query($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}}}" }
  update: { rule: "query($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}}}" }
  delete: { rule: "query($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}}}" }
  query: { OR: [
    { rule: "query ($username: String!){queryPet{owner(filter:{name:{eq:$username}}){id}} }" }
    { rule: "query ($username: String!){queryPet{owner{friends(filter:{name:{eq:$username}}){id}}}}" }
  ] }
) {
  id: ID!
  name: String! @search
  breed: Breed!
  owner: User! @hasInverse(field: "pets")
}
type Breed @auth(
  add: { rule: "{$role:{eq:\"admin\"}}" }
  update: { rule: "{$role:{eq:\"admin\"}}" }
  delete: { rule: "{$role:{eq:\"admin\"}}" }
) {
  name: String! @id
  pets: [Pet] @hasInverse(field: "breed")
}

So if we take this schema with these @auth directives, add the Dgraph.Authorization comment string to parse JWTs, and deploy it on Dgraph Cloud, we would have a full backend generated with a complete CRUD GraphQL API that is backed by a real graph database (all in one layer) that can scale to terabytes of data. But that was not all, now you can see how it can also handle auth in the core without adding any middleware add-on.

We did not just add a single type of authorization, but we did added rules with three forms:

Role Based Access Control (RBAC) rules that use roles in the JWT to grant access
Attribute Based Access Control (ABAC) rules that use a GraphQL query to filter the root nodes looking for a specific attribute property such as isPublic
Graph Based Access Control (GBAC) rules that traverse the graph to find deeply nested related nodes that can be related to data in the claims of your token.

If you are interested in learning more, stay tuned for my next article on using custom queries and mutations to link to external data and performing advanced queries using DQL, the query language for Dgraph developed with GraphQL in mind, but with functionality needed for a database query language.

Photo by FLY:D on Unsplash

A Backend with Flexibility

verneleem — Fri, 12 Nov 2021 16:04:52 +0000

When it comes to backend development, flexibility is not a common word. But why not given that everything else in the tech world is all about flexibility? Think about it, tablets are convertible to laptops and cell phones now double as wi-fi hotspots. Almost every new piece of hardware or SaaS platform is built for flexibility to serve multiple purposes and use cases.

For the most part, backends are very rigid systems. RESTful APIs always return a full dataset for a given endpoint even if you just want a specific field-set from the dataset provided.

When GraphQL came on the scene, it was made as a way to give a backend flexibility, but there was only one problem, the backend of the GraphQL layer was still very rigid. GraphQL is language and database agnostic meaning that it can be implemented with a variety of programming languages and backed by any database model including rdbms and noSQL databases. Since GraphQL is not a data storage engine, but only a layer on top of an existing database, this grows the complexity of application development. Not only does a full stack developer need to define their data structure in their GraphQL schema, but they also need to design the models of their data structure in their database.

Spanner-like tools such as Hasura came to the scene and attempted to make this easier to help generate much of the boilerplate, but the problem is that no matter how much these spanner tools auto generate, there is still a rigid disconnection between the GraphQL API and the database layer. GraphQL APIs allow front-end developers to easily query deep relationships in the database. What would take dozens of lines of code to join tables simply becomes asking for the nested field that links to the type.

For example let's look at how one might query for a users list of friends and then find other users who have pets of the same breed.

SELECT
  user.name AS user_name,
  friend.name AS friend_name,
  pet.name AS pet_name,
  pet.breed,
  owner.name AS owner_name
FROM
  users user
  LEFT JOIN users_have_friends pivot_u_f
    ON user.id = pivot_u_f.user_id
  LEFT JOIN users friend
    ON pivot_u_f.friend_id = friend.id
  LEFT JOIN pets pet
    ON friend.id = pet.owner_id
  LEFT JOIN pets breed
    ON pet.breed = breed.breed
  LEFT JOIN users owner
    ON breed.owner_id = owner.id
WHERE
  user.id=1

Response:

user_name	friend_name	pet_name	breed	owner_name
Tony	Terry	Bella	Yorky	Heather
Tony	Terry	Bella	Yorky	Brian
Tony	Amanda	Anna	Dachshund	Becky
Tony	Amanda	Anna	Dachshund	Becky

Compared to a simple GraphQL query requesting the same data:

{
  getUser(id:1) {
    name
    friends {
      name
      pets {
        name
        breed {
          name
          pets {
            name
            owner {
              name
            }
          }
        }
      }
    }
  }
}

Response:

{
  "data": {
    "getUser": {
      "name":"Tony",
      "friends": [
        {
          "name":"Terry",
          "pets":[
            {
              "name":"Bella",
              "breed": {
                "name":"Yorky",
                "pets":[
                  {
                    "owner": {
                      "name": "Heather"
                    }
                  },
                  {
                    "owner": {
                      "name": "Brian"
                    }
                  }
                ]
              }
            }
          ]
        },
        {
          "name":"Amanda",
          "pets":[
            {
              "name":"Anna",
              "breed": {
                "name":"Dachshund",
                "pets":[
                  {
                    "owner": {
                      "name": "Becky"
                    }
                  },
                  {
                    "owner": {
                      "name": "Becky"
                    }
                  }
                ]
              }
            }
          ]
        }
      ]
    }
  }
}

As you can see the two queries return the same data, but with SQL the query is complex to write with all of the joins, and the response is a flattened table. With GraphQL, the query is very simple declaring the fields and relationships wanted, and the response takes the same shape as the query which saves from repeating data in every row of a table. GraphQL also allows the client to be aware of the shape of the data returned and makes it clear how many unique responses were returned on every relationship. From SQL with only the given query, it is impossible to know if there are four users named tony or if that is the same user with 4 pets, or is that only 2 unique pets. GraphQL solves all of this and adds flexibility into the backend.

But GraphQL is just a layer right? If GraphQL is just a layer, then the actual data still needs to be stored somewhere. Since the inception of GraphQL, implementations have been using rdbms and noSQL databases to persist the data. But this adds complexity, when what developers need is simplicity. If using GraphQL means that a developer has to maintain both a model in GraphQL and a model in the database, then there is the possibility that these models may be altered and break the whole GraphQL layer. This is not even to mention that resolving GraphQL deeply nested relationships creates a dreaded "N+1" problem which happens when multiple queries to a database are needed to resolve a single query operation. These query requests can grow by a factor of N given that N represents the count of parents in the relationship model.

So how does one create a backend that fixes these problems of rigidity, reduce complexity, and at the same time keep the flexibility of technologies like GraphQL?

Let me introduce you to Dgraph! Dgraph is a spanner-like backend solution that at its core is a key-value store, but at the API level provided as an endpoint inside of the core provides a GraphQL API.

With one GraphQL schema, a user can achieve a fully generated production ready GraphQL API WITH persisted storage. To make this even easier for developers, Dgraph Labs launched Dgraph Cloud which provides a BaaS in 2020 so users can deploy all of this in less than 5 minutes. A Shared instance in Dgraph Cloud with High Availability with up to 25 Gb of storage is only $39.99/mo. You can also try it out for free with the daily limitation of 1Mb of data transfer.

To generate a production ready GraphQL API with complete CRUD built in for the above examples, we could use the following schema:

type User {
  id: ID!
  name: String! @search
  friends: [User] @hasInverse(field: "friends")
  pets: [Pet]
}
type Pet {
  id: ID!
  name: String! @search
  breed: Breed!
  owner: User! @hasInverse(field: "pets")
}
type Breed {
  name: String! @id
  pets: [Pet] @hasInverse(field: "breed")
}

After deploying this schema to Dgraph, we can use the generated GraphQL API to do all of these following tasks:

Add users with the mutation addUser
Add Pets with the mutation addPet
Add Breeds with the mutation addBreed
Add a new user with their new pets, and linking to existing breeds all in a single mutation using the addUser mutation and providing JSON input
Update a Pet and change the owner using the updatePet mutation
Delete a pet using the deletePet mutation
Update User's names using the updateUser mutation
Add relationships to friends which automatically build the inverse relationships indicated by the @hasInverse directives in the schema
Traverse the graph by querying a breed, finding all pets by that breed, and find all of those pet's owners using the queryBreed or getBreed queries
And so much more!

Did I mention that Dgraph is production ready for your startup? In the next article, I will write how to add access control and use the Dgraph datastore as the source of truth for authenticating users and granting authorization based on roles [RBAC], attribute based access control [ABAC], and graph based access control [GBAC] all while using simple GraphQL query rules!

Photo Credit: Photo by John Barkiple John Barkiple on Unsplash