Above is a big reason for not directly exposing a Dgraph’s Graphql api to clients as not all users should have full read and write permission to every defined type in a Graphql schema. While Dgraph’s Graphql interface is amazingly powerful by creating all the base CRUD APIs from schema, for use in real apps, there needs to be a way to define user roles, and what roles have read/write access for each type.
Also, expect to see GraphQL subscriptions and authorization and authentication features built in. For existing Dgraph users, we’ll be adding features to boot your existing schema into GraphQL and ways you can define your own queries backed by whatever GraphQL± you like.
Can a Dgraph dev share with us what’s being worked on regarding “authorization and authentication features”? This, together with custom logic in resolvers for validations and external API calls, would turn Dgraph into a full blown Graphql server with all the features and scalability of Dgraph underneath for customizing APIs that’s been “generated”.
You can always use the GraphQL as part of another server that has auth built into it, exposing it straight to the world is not the only thing you can do, and till we have auth built-in, it’s not something you should do at all.
Don’t expose your DB without adequate security … that’s just bad
ACL works in GraphQL, just like normal
In general, following the specifications created by GraphQL Devs/foundation. We should not impose an Auth approach, as there are several and each one with its own particularities. And many tend to evolve a lot. In practice this takes more work to maintain.
I believe that with the new customization features coming, you will be able to do any type of Auth approach. Different from what the Core Team chose.
Yes we are starting to work on both custom logic and authorisation.
As you point out, both are really important features for real apps, so I’d love to get some community feedback and involvement as we build those out to make sure they hit the right spot. Of course, all the branches and PRs will be public, but I’d also love to get a feedback mechanism going with those.
It’s not specifically for Dgraph, but some of its principles or approach might be applicable as folks dig in. I’ve been writing a package for directive-based, fine-grained access control to use with neo4j-graphql-js that modifies filter arguments in the GraphQL query document AST to ensure connection to an arbitrary ACL path – could be extended to any GraphQL backend that uses a similar “filter” argument API.
My git repository is: imkleats/neo4j-graphql-deepauth. I lay out the more general AST translation approach in a separate repo: imkleats/graphql-ast-tools. I’ve been posting about my thoughts and design decisions in a series of articles on dev.to/imkleats as well.
Not suggesting this is the only way, the best way (or a “good” way), or even a way someone else hasn’t already thought of or implemented previously. I just thought I’d share to help facilitate those creative juices flowing.
Edit: @michaelcompton, I forgot to mention (since it’s a little off-topic for the thread) that I think the GraphQL query Document decomposition in imkleats/graphql-ast-tools could also be used to implement variable blocks in your Dgraph GraphQL queries.
A thought/feedback on integration the community (me) is likely looking for.
For bigger apps, Apollo Federation would be a great, emerging-standard way to integrate Dgraph. Dgraph’s schema would be federated, custom logic can then be be done with middlewares mixed in, like graphql-shield for permission. I see this as the ideal way to fit Dgraph into a microservices architecture, with Dgraph as the main driver behind the main service while federating other services (like Auth) in an org.
So my question is, will Dgraph support custom logic in a way that Federation can be supported with Dgraph as an “Implementing service”? See docs at https://www.apollographql.com/docs/apollo-server/federation/implementing-services/. From what I can tell, Dgraph’s generated graphql server already meets all the expected types and resolvers in an Apollo sub-service. There just needs to be a way to build it as something equivalent to
const server = new ApolloServer({
schema: buildFederatedSchema([{ typeDefs, resolvers }])
})
Again, thanks for all the work you are doing and the fund raising recently as validation of your revolutionary approach to rethink the database in a graph(ql) schemas world. I’m watching with keen interest for using it potentially in a large greenfield project at my company.