Product Roadmap 2019

[manishrjain]

Here's the product roadmap for 2019:

• Stronger Type System
• Support official GraphQL spec natively (#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/

[junknown]

Hi, no plans for open chyper support yet?

[manishrjain]

No concrete plans for Open Cypher yet. We'll see about that if that changes and the year progresses.

Re: /graphql endpoint, once we have that in place, we'll see what all functionality is provided by existing frameworks like Apollo, and what we need to build as a database. Of course, we want to prioritize the security of data, but at the same time, we don't want to "become" Apollo.

[junknown]

maybe a simple open cypher to graphql+- conversion engine can help those of us still stucked with a neo4j backend that wants to scale with dgraph,i wonder if, meanwhile,it Is possibile to build It externally as library

[smolinari]

Re: /graphql endpoint, once we have that in place, we'll see what all functionality is provided by existing frameworks like Apollo, and what we need to build as a database. Of course, we want to prioritize the security of data, but at the same time, we don't want to "become" Apollo.

That is smart and for that reason, I think it would be a wasted effort to offer a pure GraphQL connection to Dgraph, with the intentions of using Dgraph as a "backend" for client-side apps. There must be a layer of business logic in front of Dgraph and behind the GraphQL endpoint for any sized application to be safe and work smartly.

Scott

[D1no]

Every few months I jump in to check on dgraph and I am excited to see manifested plans for GraphQL. I believe dgraph has the potential to become a go to general purpose dB for apps.

For anyone asking about authentification, sanitisation and similar: The standard practice is to have (in this case) dgraph run behind something like graphql-yoga which is the server component that adds the business logic / authentification layer.

In practice, every production GraphQL system looks like this:
Prisma / AppSync / PostGraphile / dGraph <—> GraphQL Server <— GraphQL Clients (Web, Mobile, other Servers etc)

As soon dGraph supports standard spec graphQL, its DB power can be stitched to the GraphQL Server. The server handles auth, caching, stitching of other sources and serves the clients.

On first glance, it might be a little confusing to conceptually differentiate the components. Anybody coming by, might want to read this post and that comment:

• What the hell is Prisma, the GraphQL thing?

In my advisory work regarding GraphQL, I often have this Q&A (copy past)

Question

If dGraph / Prisma / PostGraphile itself already provide a GraphQL interface (i.e, it is a GraphQL server already), at what situation do we need another layer of Apollo-server or graphql-yoga?

I don’t see any extra benefit adding another layer. Can you shed some light on this?

Answer

To provide additional logic like access control etc. I.e. Prisma does not support roles and can’t make a difference between a logged in/out user.

Also, the GraphQL Server is able to sticht multiple GraphQL endpoints (Schemas) together.

So one can use an old MySQL database via Prisma jointly together with a GraphQL wrapped REST API of 3rd Party Providers, access & security logic all together with new data stores like graph and key-value dbs for incremental / feature based adoption.

Question

Why are there so many graph ql servers?

Answer

Conceptually, GraphQL is a REST replacement allowing a new form of communication. Just like you might string together services based on REST, you string them together based on GraphQL. Only with the advantage, that GraphQL is self documenting, allowing an automatic merger of all the functionalities in the upstream chain without manually fetching & joining REST calls.

To communicate, a GraphQL endpoint needs to be served. This however, is not to be confused as having to be “the Server Endpoint” to i.e. public web and mobile clients.

[smolinari]

Prisma / AppSync / PostGraphile / dGraph <—> GraphQL Server <— GraphQL Clients (Web, Mobile, other Servers etc)

This isn't quite correct IMHO. It would be more like this.

MongoDB<—>Prisma -|
MySQL<—>Prisma -|<— GraphQL Clients (Web, Mobile, other Servers etc)
PostGres<—> Prisma -|

or

PostGres<—>PostGraphile-|<— GraphQL Clients (Web, Mobile, other Servers etc)

or

all kinds of backends<—>AWS Appsync-|<— GraphQL Clients (Web, Mobile, other Servers etc)

or maybe

Dgraph<—>GraphQL-Yoga-|<— GraphQL Clients (Web, Mobile, other Servers etc)

or also maybe

Dgraph<—>Business Logic Server<—>GraphQL Gateway-|<— GraphQL Clients (Web, Mobile, other Servers etc)

In other words, Dgraph shouldn't be placed in the same boat as Prisma, AWS AppSync or PostGraphile. It is ONLY a database, currently and I highly doubt it will get to be much more or rather, I don't think it should. Again IMHO.

Scott

[D1no]

This isn't quite correct IMHO. It would be more like this.

MongoDB<—>Prisma -|
MySQL<—>Prisma -|<— GraphQL Clients (Web, Mobile, other Servers etc)
PostGres<—> Prisma -|

Prisma is only an adapter for managing old school databases via graphQL (table creation etc) and should not talk to the public directly as it doesn’t provide access logic (just like a DB). As its website header says “Prisma replaces traditional ORMs”. It would be like having mongoose for mongoDb exposed to the public. Its possible, but not advised. Beside, the whole point of GraphQL is to have one request to serve everything in one query response. The diagram above would mean clients have 3 endpoints to manage and would have to merge & cache themselves. A graphql server is the one caching and stitching. I.e. for serving a nice friend list feature, taking the userId from MySQL (via prisma), friends common connections / graph relations (from dgraph) and Analytics data (from a wrapped REST API from BigQuery) neatly packed to the frontend.

So native GraphQL support through dgraph is baisically just that = “prisma” + db. Or Postgres + PostGraphile, or Neo4j + GraphQL Plugin. So it very well lives in the same boat and would be a great alternative.

On a side note: AppSync is a very different thing in the list. AppSync is like GraphCMS, meteor, or to be understood as a firebase solution in GraphQL.

When dgraph is bringing GraphQL support, its nothing more than a dB with a smart REST / GraphQL interface for easy stack integration. And that is great.

[smolinari]

I was assuming yoga was in front of Prisma.

To be more correct, it should be this.

MongoDB<—>Prisma -business logic-GraphQL-Yoga-|
MySQL<—>Prisma -business logic-GraphQL-Yoga-|<— GraphQL Clients (Web, Mobile, other Servers etc)
PostGres<—> Prisma -business logic-GraphQL-Yoga-|

The point I was trying to make overall was, Dgraph shouldn't be connecting straight to GraphQL Clients (outside of servers).

Scott

[D1no]

The point I was trying to make overall was, Dgraph shouldn't be connecting straight to GraphQL Clients (outside of servers).

Haha 😅 then we just missed each others note. You are absolutely right: Dgraph GQL should not be exposed to public consumers and therefore should not bring yet another user/role manager.

[styk-tv]

@smolinari Thanks Scott. Your explanation lead me to https://github.com/maticzav/graphql-shield which is a dream come true.

[smolinari]

@D1no - Actually, I think Dgraph does need a user/ role management, because that would offer a way to get a form of logical separation within a database for the purposes of multi-tenancy. What Dgraph doesn't need is to have an extra GraphQL API as mentioned here:

We will have a different endpoint called /graphql or something, which would run GraphQL queries.

The current GraphQL API should be specs compliant to begin with (and even then, GraphQL Clients outside of other servers shouldn't connect to it directly). I understand trying to keep backwards compatibility, but they shouldn't have broken away from the spec to begin with. That's what specs are for. 😁

I guess if the new endpoint is to offer a specs compliant GraphQL API and it wasn't intended for client-side access (as in devices on the web) and at some point in a major version, GraphQL+ will be deprecated, then I guess I am for it too. I might have misunderstood the issue that started it all, as the OP was talking about Relay and Apollo, which are client-side (as in devices on the web) libraries. If that was my misunderstanding all along, then I apologize for wasting everyone's time. 😄

Scott

[styk-tv]

That makes me curious, please consider this: If /graphql is not to be used directly by the clients (no jwt auth mechanism, not recommended to be exposed outside) then what is the point of /graphql endpoint built in? In neo4j ALL my interactions with the db are using neo4j-graphql-js using bolt protocol (not through /graphql plugin).

To follow that example, if graphdb could follow similar pattern of creating graphdb-graphql-js component then no /graphql endpoint would be necessary. Difficulty here is allowing yoga/apollo tools to setup standard graphql api, allowing transformations on schemas, permission decorators, rules in IDL as standard type/query/mutation/subscription and translating that into GraphQL+- requests with the assistance of graphdb-js driver.

This way graphdb-graphql-js component would allow anyone to integrate as they want and /graphql could then be simply an example instance of yoga/apollo with several examples potentially demonstrating permissions graphq-shield or custom schema directives, middleware and so on.

[bandirsen]

Since GraphQL endpoint usually consumed directly by public client, I vote that GraphQL support as new Dgraph client API that can be only used by Dgraph client or separate GraphQL-Dgraph conversion package/library, rather than opened to public /graphql endpoint.

First reason, just like some others already state, separated security/auth/authz will be a problem, I'm afraid at the end Dgraph will be pushed to be an oauth/openid client, while not all of us using it, Dgraph should be remain agnostic to that kind of technology.

Second reason is performance, conversion from GraphQL query to Dgraph query would be a resource intensive, let the backend app server handle it, while Dgraph server focus on dealing with database.

Third reason is confusing multiple schemas, GraphQL it self can have more than one schemas (for public, for admin, etc) let this GraphQL schema variation and GraphQL query validation handled by backend app server before sent it to Dgraph.

[D1no]

That makes me curious, please consider this: If /graphql is not to be used directly by the clients (no jwt auth mechanism, not recommended to be exposed outside) then what is the point of /graphql endpoint built in?

• ❌ Clients: End-User Devices
• ✅ Services: Other GraphQL Microservices & Middleware

@styk-tv A GraphQL API is like a very smart Rest API. You can use it to serve clients on the web (browser, mobile app etc.) or other services (apache server, BI, data warehouse etc.). The later is meant for dgraph — spec compliant GraphQL means seamless service to service communication.

similar pattern of creating graphdb-graphql-js component then no /graphql endpoint would be necessary.

Graph QL is language / library independent; i.e. I have a C# & Erlang service that consume GraphQL. It respects the spec, and anything that supports the spec can be easily integrated. That is what the endpoint is for. It elevates access via protocol instead of library transform logic, providing to any language:

• Automatic merging of schemas with other services
• No need for ORM code
• Self documenting api for both consumption and mutation

The Gateway (like Apollo, shield etc.) deals with Auth/Roles etc and is completely unrelated to the DB. Those libraries are merely a wrapper for GraphQL spec.

Credit: Adapted from @schickling and a pretty good post about Service to Service in GraphQL

I.e. Service to service means, you could build graph analytics of open source commits in dgraph and merge them effortlessly with GitHubs GraphQL API to go even deeper.

[styk-tv]

@D1no I think fundamentally we're talking about the same thing. Let's use terminology from your diagram. My interests are in GraphQL Gateway (with OpenID) so parts of the token data can participate in the queries (like who is the user or what groups they belong to). Microservices layer needs to understand the database. So in order not to mix and not to retype the schema of the database in the Micoservices layer you need a smart set of components so you can define security against the schema. Currently this can be COMPLETELY abstracted using two methods in my case. By using neo4j-graphql-js i have control over schema augmentation to autogenerate queries, mutations and subscriptions as I see fit without rewriting resolvers (or by writing only the ones I want leaving types autogenerated) As well as in the same schema definition I can have Role(Group)-Based-Access-Control defined (graphql-shield with openid) not only per query/mutation/subscription but also on field level. (again without retyping my resolvers which is a massive job especially when you have multiple siloed teams doing it). Above BTW is 100% reality with only two npm's. This 95% decrease in effort of Gateway+Microservices is what this discussion should be about. This is not 2013.

Now in regards to language its the community adoption rates that should drive focus initially. Personally you may have C#, Erlang or I may have Python or @manishrjain may have Go but you can't ignore adoption and effort that goes into Node for Yoga/Apollo for the GraphQL Gateway and Microservices layers from your diagram. It would be silly to ignore this if this project want's to truly participate in GraphQL community. So having said that focus on Node.js (npm) component dgraph-graphql-js in my humble opinion should be considered as part of dgraph 2019 roadmap. Disconnected from the actual database but growing at its own pace and maintained by independent individuals but still in sync with dgraph growing db capability.

[brianbroderick]

👍 I'm happy to see upserts on the list for 2019.

While it's possible with custom code inside a transaction, it's fairly brittle since all writes to these nodes would need to run through this custom code. If someone isn't aware of this (or if the db is accessed from outside application code), duplicate records can easily be written.

It also makes the application code unnecessarily complicated.