I consider myself a full-stack developer, but I lean toward the front-end. That is probably because I am a visual learner (i.e. I process information easier if it is presented in a visual format). My assumption is that many front-end developers are also visual learners. When I learn a new concept, if I can see a picture or a video of that concept then I am able to process that information faster and retain that information longer.
That was the case when I was first introduced to graph databases. At first, the concept of storing data in nodes and then creating relationships with edges was strange because it was so foreign to the relational and document database concepts that I was used to. But after I used a data explorer to see how my data was organized into a graph, things clicked.
To be quite honest, graph databases are so intuitive to me now that it is difficult for me to switch back to relational and document databases because I can’t easily visualize those data and their relationships.
So when I say that graph databases are perfect for front-end developers, I am saying that their data models work really well for people who process information visually (i.e. visual learners).
In this article I will introduce you to a graph database called Dgraph. I accidentally stumbled upon Dgraph a few months back, but it is pretty new and doesn't have a lot of tutorials about it. So I wanted to introduce it here for those of you who are evaluating graph databases (or any database) for a new project.
Before I get into Dgraph, if you do not know what a graph database is, then read here for a nice overview: What is a Graph Database?
Also, I want to share this bit of information that tripped me up about graph databases at first:
When working with graph databases, the term "graph" is often used instead of "database" or "data". For example, when creating a new database, you might read something like this: "Now it’s time to create our graph." In this case, graph means database. Or when designing the schema for your graph database, you might read something like this: "When designing your schema, you will think in terms of the graph that matters for your app." In this case, graph means data.
Just keep that in mind, when working with graph databases.
In Part 2, we will get started by running Dgraph in a Docker container.