Why isn't the graphql.dgraph.io website ever mentioned on the main website?

I just accidentaly encountered graphql.dgraph.io from a forum answer, and it seems to be a major feature, why isn’t it ever mentioned on the main website ?. I spent months building a graphql api atop dgraph, and this could have helped make the job easier. Yet for some reason there isn’t even a link connecting the documentation pages to graphql.dgraph.io.

1 Like

Hi, glad you like the features. Please use and let us know how you go.

We did post a blog announcing our GraphQL features in late October.

Currently, those features aren’t in a Dgraph release, we’re moving fast towards that and you’ll see those docs improve and more links to them when that happens.

1 Like

So is this only available if you use the docker image dgraph/standalone:graphql? Can’t use this through the shell script install method?

Is there a roadmap for getting it into releases? Is it something that is planned for Enterprise only, or will it be part of the community release?

Hi, GraphQL support will be part of the free features pretty soon - should be early next year.

1 Like

Hi, this seems nice for simple crud ops. Are there any hooks planned, so that you can customize the queries wich are performed against dgraph? auth, filtering, additional queries before/business logic?

@michaelcompton is there any update on GraphQL in DGraph?

The standalone GraphQL docker image hasn’t been updated for ~2 months.

Theoretically, it sounds all good on paper, but but practically, I tried to assemble a deployment.yaml for Kubernetes and it really is a major PITA. Apparently, there are no regular GraphQL builds or docker images. When scrolling through GH, the most recent branch seems to be the mjc/graphql.

Looks like, I have to build from that source to build an up to date docker image myself.

Is that the normal way of handling a feature preview in DGraph?

https://github.com/dgraph-io/dgraph/commits/mjc/graphql

@stroboshaver yes we have plans for custom logic and customising the actual GraphQL± queries that get run … look out for these in the coming months.

@marvin-hansen Hi, yes we built out that support on a set of branches so we didn’t pollute master before we were ready to release. mjc/graphql has now been merged to Dgraph master, so it’ll get released real soon now.

1 Like

@michaelcompton FTW - awesome! You are the hero of the day!

@michaelcompton

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

https://github.com/dgraph-io/dgraph/issues/4580

Thanks for reporting it. Looks like it was a docker networking issue.

Solved on the linked Github issue.

@michaelcompton Thanks a lot for your work on the GraphQL stuff. This Docker issue was relatively quickly resolved with a new Docker compose file. I saw a lot of buzz in the GH commit log recently, and the last time I pulled the docker container build from the master branch, a lot of stuff has improved.

I understand GraphQL support is relatively new, still in the making, and may need some more work, but what I saw yesterday was pretty encouraging.

Thank you for all the amazing work & ongoing effort!

Hi,
while messing around with the current implementation of your query and mutation rewriters
two questions arised:

  1. Are you going to support subscriptions?
    (i know its a little bit harder in a distributed environment - the apollo server has a nice implementation how to handle subscriber connections via your own distributed messaging system (you can easily use Redis, Kafka or RabbitMQ)

  2. Currently there are no built in hooks for additional business logic, which is applied on the serverside exclusivly (like automatically adding createdBy/createdAt/updatedBy/updateAt predicates) or kind of “row-based” filters (e.g. automatic filter nodes by belongsTo uid predicate of user) etc…
    I implemented some ideas but since queries can be constructed in a complex manner things like auto filter sometimes need to result in additional var queries, where query variables for the actual query can be declared etc.
    Are you currently working on those serverside features, or are they even on your roadmap?

Best Regards.

Hi, thanks for the question.

  1. Yes we plan to support subscriptions. It’s going to be in the first release, which is landing real soon, but is likely to be in the next chunk we work on just after that.

  2. Same story - not in the first release, but we have some ideas and will be looking at it soon.

Hi,

i messed around with the graphql package on the master branch.
How ever i ran into multiple issues.

  1. It would be great if graphql introspection query for queries and mutations would return queries and mutations with all additional types (e.g. filter types) for all auto generated crud options.
    This is needed so that its easy to integrate it into you frontend toolchain (I create strong types, queries/mutations and subscriptions with apollo client codegen)

  2. Make The Executors and Rewriters dependency injectable.
    I implemented some custom logic to the query rewriter and the mutation rewriter.
    graphql is parsed by vektah package wich i already use in many projects with gqlgen.
    The parsed query is then rewritten with the help of the gql package (filter trees and children etc.).
    So it is very easy to add custom logic e.g. apply conditional filters on the serverside based on jwt sub etc.
    Main Problem is that the executors are written for an integration into alpha - to make and spin up the whole project is just to much for every small change in the graphql layer.
    I tried to import the dgraph package and start my own webserver with just the two routes to admin and query resolvers. Of course i had to change the query executor to do calls via dgo.
    Currently AdminExecutor and DgraphExecutor share the same implementation.
    Please consider to refactor the Query and Mutate function in dgraph/execute.go so that they hang of just from a DgraphExecutor struct.
    This way on easily could implement a DgoExecutor and swop that in via di if the graphql package is needed from “the outside”. It also would be superb if you can make the Rewriter Functions injectable, so one can spin up a fully customizable graphql server with minimal effort by just importing the graphql package and inject some stuff.

Thanks you for your great work so far!

Hi, thanks for your detailed comments and questions

For (1), I’m not sure what you mean? Introspection responds with the full schema, scalars, your types, and generated types. Do you have a particular query that’s returning an incorrect result.

For (2), You’ve mentioned some interesting ideas. Our first release won’t have support for custom logic through Dgraph. We are expecting to work on adding that support in the future.

For (1): Thank you very much - indeed my query was wrong and it did not report the queries and mutations correct. Now i can grab the whole schema in graphql or json format correctly from the respective endpoints. Codegen client side works fine, too.