Product Roadmap 2019

[manishrjain]

Here's the product roadmap for 2019:

• Stronger Type System
• Support official GraphQL spec natively (Make Dgraph work with standard GraphQL #933).
• Live streaming of updated responses
• Gremlin support
• Full JSON support across exports, bulk loading, and live loading.
• Upserts

Enterprise features:

• Binary backups
  • Full Backups
  • Incremental Backups
• Access Control Lists
• Audit Logs
• Encryption at Rest
• Dgraph cluster running across remote regions
• Point in time recovery

Tell us what more you'd like to see happen in 2019!

[smolinari]

Would be nice if ACLs could be in the Community Edition.

Scott

[smkhalsa]

@manishrjain Thanks for the update! Can you share any info about how you intend to implement the GraphQL spec while preserving the existing functionality? Custom directives?

As for Live Streaming, will this simply be the Subscription portion of the GraphQL spec, or do you intend to implement live queries (such as with a @live directive?)

[styk-tv]

Would be totally awesome if we could have a chat about OpenID and protecting schema queries based on roles from the JWT tokens. https://blog.grandstack.io/authorization-in-graphql-using-custom-schema-directives-eafa6f5b4658. If required I could provide full time OpenIDConnect server (Keycloak) on a public endpoint for the duration of the implementation/testing.

[manishrjain]

how you intend to implement the GraphQL spec while preserving the existing functionality? Custom directives?

We will have a different endpoint called /graphql or something, which would run GraphQL queries. That way we can maintain and improve what we currently have, while also supporting GraphQL official spec.

[vespertilian]

Any chance of you offering a paid managed instance?

[smkhalsa]

We will have a different endpoint called /graphql or something, which would run GraphQL queries. That way we can maintain and improve what we currently have, while also supporting GraphQL official spec.

@manishrjain For clarity, are we to understand that the /graphql endpoint would only implement a subset of the GraphQL+- API? Beyond backward compatibility, what are the reasons to stick with GraphQL+-?

[manishrjain]

GraphQL+- implements a lot of features, which are not part of the GraphQL spec, like variable assignment, math operations, shortest path queries, and so on. GraphQL isn't the right fit for all the features that one needs from a database.

But, GraphQL is a great language for apps to be built on -- and that's the aim here, is to support it to allow building apps easier on Dgraph. Dgraph is a great graph DB, but also a great, general purpose primary DB for apps; and we see more and more people/companies use Dgraph to build apps.

Any chance of you offering a paid managed instance?

Not a priority. It would depend on how things go in 2019, and whether we have the resources needed to pursue what would effectively be another huge project (almost a mini-company) within Dgraph.

[liqweed]

Support for multiple databases (schemas) on the same server is very important for us for the reasons mentioned in the relevant issue
#2693

[smolinari]

But, GraphQL is a great language for apps to be built on

So, the intention is to have a standard GraphQL endpoint, so apps can directly access the Dgraph server?

Scott

[styk-tv]

For outside-living apps like Web/Cli/Mobile you will still have to have an authentication proxy on query/mutation level. Which is going in the direction of neo4j plugin system. Not complete.

Wouldn't it make more sense to add role-based-access-control based on OIDC? So Queries/Mutations can be protected by simple group decorator, then user's signed token has to contain list of groups user is subscribed to. Entire implementation of token verification is in this one file on Kubernetes repo. https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/oidc/oidc.go A good place to start.

This would make it possible to expose /graphql endpoint to the world without having to rewrite every single call inside of API that ends up calling unprotected /graphql endpoint or with ACL's that don't fit authorization standards of any of the modern Web/CLI/Mobile apps.

[smolinari]

@styk-tv - There is also still the very important part of web interaction called user input sanitation, which is just as much, if not more, of a security aspect than RBACs or ACLs. I mean, we don't want to run into little Bobby Tables, right? 😁

How will Dgraph also handle user input sanitation (and the other things mentioned in that article linked to little Bobby)?

Scott

[styk-tv]

Scott, Yes, graphql injections are real. So question is will dgraph as community work out authorization, DoS, injections or just say hey, here is /graphql we have worked out this issue or follow footsteps of bare graphql and let Apollo grow into a superpower?

• https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
• https://staaldraad.github.io/post/2018-03-16-quick-win-with-graphql/