Is Dgraph suitable for our project?

[Liuz]

Hi everyone,
I’ve been reading documentation, tutorials and watching some videos from Youtube related to the Dgraph. However, I’m not sure if the Dgraph is the correct solution in our case.

What we try to do

We are building a relatively small graph where each Node has the same properties; name, type, and UUID. The information is coming from a third-party system and we have no control if and when new types are added.

As an example of we could have the following:
[type:City, name:RandomVille]->[type:building, name:“Factory”]->[type: machine, name:BS-generator]->[type:temperature, name:“Temperature”]

There could be multiple cities and buildings in a city, with multiple machines and maybe even machine parts, etc.
And we would like to make queries such as:
Retrieve all “temperature” type nodes connected to this city, etc.

DQL and GraphQL

When I watched the first introduction videos (from the year 2019?), I was thinking that the Dgraph would be suitable for this project. But after researching, I’m not so sure anymore.

By my understanding using GraphQL is not suitable for this type of purpose, because it is strongly typed. The DQL might be suitable for getting connections like this, but it is not recommended for public use:

• When the client cannot be trusted, such as with javascript applications that run in user environments.

• When you don’t want to give your clients access to drop your database or alter your schema.

• When you need to restrict access control at the object level. (Enterprise users have access control at the predicate level within DQL)

Above bullet points are taken from the GraphQL vs DQL blog post:
[GraphQL vs DQL - Dgraph Blog]

We are planning to provide this information to other organizations, probably by using an API key, but you cannot trust that the keys will stay safe. It might be possible to block requests against “mutation” endpoint, but I’m not sure if this is enough?,

Dgraph has many use cases, but is it suitable for our case and if not, does anyone have idea where to look next?

Edit:
When I made some final edits before posting, I accidentally removed the GraphQL vs DQL reference.
Edited the original post by adding reference to the post.

[BenW]

@Liuz

The DQL might be suitable for getting connections like this, but it is not recommended for public use:

This doesn’t fully answer your question, but you can embed DQL in custom graphql queries that you define, and then specify auth rules for those queries. So perhaps that would be a solution?

[MichelDiz]

@Liuz

The DQL might be suitable for getting connections like this, but it is not recommended for public use:

Well, neither DQL nor GraphQL should be “for the public” but for “machines”. With DQL you have to build your API and Dgraph should talk only with it. With GraphQL you can set up the Auth feature.

@Liuz

When the client cannot be trusted, such as with javascript applications that run in user environments.

If you have a good API, no language is a barrier. Nothing bad happens to the one who takes care of the bridges of your business.

@Liuz

When you don’t want to give your clients access to drop your database or alter your schema.

They only would do it if you allow it. No Admin endpoint or GraphQL admin(which is a separated GraphQL server just for admin functions) should be exposed to users/public.

@Liuz

When you need to restrict access control at the object level.

The GraphQL Auth feature is Object Level if I’m not mistaking. But in DQL you have to build your own.

@Liuz

It might be possible to block requests against the “mutation” endpoint, but I’m not sure if this is enough?

That’s up to you(if you pick DQL). In GraphQL Auth you gonna use JWT Tokens.

@Liuz

Dgraph has many use cases, but is it suitable for our case, and if not, does anyone have an idea where to look next?

I don’t see anything strange at all in what you said. Sure Dgraph is suitable.

@Liuz

Retrieve all “temperature” type nodes connected to this city, etc.

That’s easy.

Heres a query example

{
 
  var(func: eq(city.name,"San Francisco")) @recurse(depth: 50, loop: true) {
    GET as UID
    building.edge
    machine.edge
    anyOtherPossible.edge
  }
  
  q(func: uid(GET)) @filter(type(Temperature)){
    name
    tempValue
  }
  
}   

I’m using recurse cuz you mentioned that you may not know exactly what format the data will come from. Recurse is great when you at least know the name of the edges.

[Liuz]

Thanks for the reply.
Embedded DQL queries might not be what we are looking for, but it might be possible to provide a practical “generalized” set of these queries for our partners.

I wonder if it would be possible to use this type of query together with lambda’s [Bring RESTful Data Into Your GraphQL Responses Using Dgraph Lambda - Dgraph Blog]…

[Liuz]

Thank for the reply,
After reading your post, I realized that I screwed up while editing my original post, and forgot the blog reference from the bullet point list (This is now updated).

Using the word public was not well thought from my part. By it I refer to clients, services and developers using the API. Practically anyone allowed to access, besides my organization who hosts the setup.

The example query you provided is the thing that we are after, but in our case we cannot use types such as City, Machine, etc. As every node is referencing an external system via UUID, we are currently calling these just “Objects” that have name,type and UUID. The edge/connection types would be predefined to some degree.

Aim of the project is to provide a “map” of sorts, which allows developers to understand how everything is connected and allow them to make read-only queries for retrieving objects in a way that best suits them. The whole visualization of the graph would also be made available for the developers. This pattern would allow users to add new nodes (manually) into the system and existing services could automatically “find” the new objects that match the criteria.

Some questions:

1. DQL and Security
   Is it possible to allow read only queries to be made against the DQL endpoint by configuring Dgraph or with reverse proxy (NGINX, etc) and if it is possible, are there other risks (besides possible DoS attack / accidents with heavy queries)

2. Using GraphQL
   Based on my understanding, using GraphQL in a flexible manner that I tried to describe above is quite impossible because the GraphQL is strongly-typed and you need to define everything in a schema. Did I misunderstand something or is there a pattern for achieving this?

[MichelDiz]

@Liuz

Is it possible to allow read only queries to be made against the DQL endpoint by configuring Dgraph

Yes, you can use mutations disallow.

dgraph alpha -h | grep disallow
   --mutations string     Set mutation mode to allow, disallow, or strict. (default "allow")

This will disallow in the respective Alpha instance.

@Liuz

if it is possible, are there other risks

Crawling/scraping data. But I think the ones you’ve mentioned are the biggest ones if your data isn’t sensitive.

@Liuz

Did I misunderstand something or is there a pattern for achieving this?

Note, it is clear and you right. I was just mentioning the Auth feature and such.

As mentioned by @BenW you can use Custom GraphQL queries, remote queries, lambda and so on. The only problem is that you should build a type for that custom query. But the point is that you can use DQL’s power over GraphQL.

[Liuz]

Thank you for the information.
It is valuable to be able to ask around before you start using new things. We will probably be trying to build a prototype system with Dgraph to test things out in practice.