Pareto IRL

Short post on Pareto principle. Had you ever need to implement GraphQL API on top of some database entities with simple CRUD? Did you look through possible options to find an already working solution (with no coding required)?

If your answer is no and you just start coding - god I want to be that young and full of energy. But today I will briefly share you with a guide to use Dgraph in building of SITSkills Web Service. Yes - mature developers just took something from a shelf instead of writting from scratch =(

What the heck is SITSkills

It’s a part of my pet-project. It’s early stage and I even didn’t tell anyone in SITC I will build it. Maybe in a couple of weeks I will give up and discard the idea. Maybe it will move on and we may try to build something with other contributors. But I want to share this as an example to be close to real world application as possible.

GraphQL and Dgraph

It’s better to check official documentation if you know nothing about GraphQL. Dgraph is a “GraphQL” native database. TL;DR it’s a graph database with GraphQL HTTP API out-of-the-box.

Let’s do this!

Check the repository. To spin up a Dgraph instance you can use docker-compose configuration provided and execute: docker-compose up -d. Now when you have database up and running you need to upload schema: curl -X POST localhost:8080/admin/schema --data-binary '@schema.graphql', good.

Basically schema is quite simple:

type Skill {
    id: ID!
    name: String! @search(by: [term])
    specialities: [Speciality] @hasInverse(field: skills)
    description: String @search(by: [fulltext])
}

type Speciality {
    id: ID!
    name: String!
    skills: [Skill]
}

We have Skill with name and description, Speciality with name and many to many association between them.

These two actions already did 80% of work needed to be done in many projects. How to easily explore API we have now? I prefer Insomnia and below you will find already prepared collection of requests:

https://www.dropbox.com/s/axkcgpdugv8g7a6/Insomnia_2021-03-24?dl=0

First, we will create some skills:

mutation {
  addSkill(input: [
    { name: "GraphQL on Dgraph"},
    { name: "Databases"}
  ]) {
    skill {
      id
      name
    }
  }
}

Execute and look for a response - we won’t need identifications in our next request btw.

Thanks GraphQL - we can look for skills by names:

mutation {
  addSpeciality(input: [
    { name: "Web Developer", skills: [
      { name: "GraphQL on Dgraph" },
      { name: "Databases" }
    ]},
    { name: "Frontend Developer", skills: [
      { name: "GraphQL on Dgraph" },
    ]}
  ]) {
    speciality {
      id
      name
    }
  }
}

I think it’s fare enough to do not bother Fronted Developers with databases 😸

And the last one - let’s query our entities:

query {
  querySkill {id name}
  querySpeciality {id name}
}

I do not put results of our requests here on purpose - that way I push you to open the f#%@ing terminal and write some commands instead of reading endless set of articles.

Conclusion

There are plenty of tools in our industry. Let’s use some of them. Imagine if every plumber you ask to fix something in your bathroom will create tools instead of bringing toolbox with everything needed in advance? So to be responsible engineer you should have such one and review it from time to time.