Graph Service API

Let’s look at querying graphs.

Common interface for different graph services

The graph databases we’ll look at have web interfaces and support CRUDCreate, Read, Update, and Delete operations on graphs in their own graph stores. They all have their own APIs and data representations, which can be a bit of a burden when switching between these services.

Let’s define a common interface for these graph services. We can make use of the OTP behavior pattern to define a set of callbacks that will be implemented by any module that adopts this behavior. This allows us to define a graph service contract—an API.

API operations

• We’re looking to create a simple interface with the following operations:

  • graph_create/1

  • graph_read/0

  • graph_update/1

  • graph_delete/0

• And to these, we’ll add an optional callback if supported by the service:

  • graph_info/0

• Now to be properly useful, graph databases also generally support a query interface so that subgraphs and individual data elements of the stored graphs can be returned. For that, we’ll want to have a query service callback:

  • query_graph/1

• And for interactive querying, it’ll be handy to have a bang-style callback that returns a result value directly instead of wrapped in a tuple:

  • query_graph!/1

Visual representation

The following figure diagrams out the data flows for a couple of graph API calls on the graph service.