How to add a GraphQL endpoint to an DGraph DB already running on k8s?

Alright, I have deployed a single DGraph instance on Kubenetes and its running fine.

I did some experiments with the new GrapQL endpoint on my notebook and it does the trick for me.

Now, how can I add the GraphQL endpoint to my already running DGraph DB?

Can I just add another service?

Modify the deployment.yaml?

Sorry for the naive question, but I have a hard time figuring out how the GraphQL endpoint connects to DGraph.

I am using the single deployement file from the repo:

In the latest release candidate binary (https://github.com/dgraph-io/dgraph/releases/tag/v1.2.0-rc1) and the subsequent 1.2.0 release, alpha should already have a /graphql endpoint so you don’t need to do anything special to add a GraphQL endpoint to a running dgraph database.

Thanks @pawan

The new v.1.2-rc1 release contains a bug that prevents alpha nodes to connect with a running zero instance, as reported in the GH issue.

For about a week, I tried to evaluate if my company is going to use DGraph & GraphQL as foundation for development, and later in production. Increasingly, I feel it’s a waste of time and not worth the pain.

github.com/dgraph-io/dgraph

Hey, I have tested this issue. It really happens sometimes, but with this docker-compose, for some reason, I can’t reproduce it with the docker-compose yml bellow. Also using the local binaries (downloaded). Need to do the same in k8s context tho.

To use it:

http://ratel_http:8000/?latest

and enter the server URL
http://ratel_http:8080/

Thanks a lot @MichelDiz This actually works, at least locally.

I do like the Ngnix config you used to load balance because it also allows adding some base security, which is very much needed. I already filled an issue w.r.t. to adding the most basic security to the k8s config.

That said, I actually want to deploy DGraph with GraphQL in k8s but so far, I had no luck. With all those issues I had, it took me quite some time to get it to work and once it was successfully deployed, the default setting are so completely insecure that there is no point using it.

Is there any chance to get this done?

1 Like

Don’t thank me, thank dmai. I just edited it.

In the case of GraphQL for k8s, I suggest you wait until GraphQL is released for real or for the next stable RCs with it (Some features like “custom resolvers” are coming). Or we provide some YML. A contribution to this is welcome too.

Dgraph by default is to use behind an API. There is no security by default, only if you use ACL you will have it. Thus, you need to create an API and isolate Dgraph instances from users or another approach to secure it.

I’m sorry for your experience, but GraphQL is an under development feature and any security approach (except for ACL) is the user’s responsibility.

This is true even in GraphQL context. They don’t offer any security solutions or tips for doing it. They make it clear that security approaches are optional for each user. There are several approaches in this regard. Using JWT tokens, using Firebase, using password/hashes and so on. There are several approaches and GraphQL does not determine any of them. But we do, and it is “Create an API and isolate the instances”.

Notoriously, all YMLs that exist in Dgraph docs provide no means of isolating instances. Precisely to make access easier for people to learn to use Dgraph. You can simply modify them to get the isolation you need.

Creating APIs and other approaches can be part of “tips” we can give in blog posts and so on. But I believe every IT business has its own way of handling it. We have some examples of APIs in the Dgraph repositories. But more examples will come.

Cheers.

@MichelDiz

Thank you, and I got the message.

Thanks.

1 Like