At work, we are planning to switch from PostgresSQL to another DB solution (MongoDB has been on our radar lately). After some research, I discovered Dgraph and really liked the idea of having a Graph database as our primary storage solution. However, I have no idea on how to cleanly use Dgraph behind a Go server running GraphQL. Doing the translation GraphQL <–> GraphQL+ does not seem feasible. Even using the native GraphQL implementation of Dgraph does not seem like a solution as we do not want the clients to interface directly with Dgraph.
I saw some similar posts back in 2018 and 2017 but we have now entered 2020 and I want to know if anyone found a way to make the connection Dgraph <–> Golang <–> GraphQL.
Using the native GraphQL implementation would be the recommended solution as long as the generated APIs fulfill your needs. If the GraphQL API had authentication/authorization built in to it, would that be good enough for your use case or is there something else that you’d require to be able to use it?
Having built-in authentication/authorization in the GraphQL API would make it too opinionated in my opinion. What we need is the ability to plug in with our in-house authentication/authorization solution. Moreover, we need to apply custom logic in the GraphQL resolvers to fetch data from our APIs or perform custom validation and verification for example.
Personally, I have a discomfort exposing Dgraph Alphas’ directly to the client. Having one or more Go services in the middle is my preferred approach.
I know technically this is very challenging due to the limited spec of GraphQL but is there any provisioning to cater for the above?
Lots of other users have also asked for the ability to apply custom logic to GraphQL resolvers and we are looking into what’s the best way to provide it. We’ll have something for you soon.
Try Hasura with DGraph as an external GraphQL schema for a very soft migration on your terms.
I have the issue that I need unified GraphQL access to both, relational and graph data because certain parts of my data cannot be represented efficiently in a graph.
Are you thinking of using vektah/gqlparser for this purpose ?
We are thinking of using it but couldn t find a documentation , nor comprehensive examples to understand the parser …
Any help would be greatly appreciated , since we are pretty stucked in our project with dgraph + GO Api
@hubyhuby We are already using vektah/gqlparser within the GraphQL layer of Dgraph and would continue to do so. When we support GraphQL± queries in the GraphQL layer, then the user would not need to understand the implementation of the underlying library as that would be abstracted away.
At the risk of stepping into a zombie thread, I wanted to comment on @Mikeal 's statement about the feasibility of any arbitrary GraphQL <–> X translation.
The structure of the validation tooling in vektah/gqlparser (or really any package following closely from the JavaScript reference implementation) could fairly easily be tweaked to perform arbitrary AST translations. It currently uses a set of validation rules that are defined as visitor functions called during a walk of the GraphQL document AST which generate validation errors that are appended to an errors array.
If the errors array were converted to a map of the following structure:
type AstMap map[string]AstFunc
type AstFunc func(AstMap) interface{}
…and translation rules were written and used in place of validation rules to populate the AstMap during traversal, you can turn any GraphQL AST into one or more other ASTs of whatever language/syntax you need in a predictable way.
(edit in case it wasn’t apparent what I meant: The AstMap/AstFunc construct allows for the lazy evaluation of AST components that might not have not been reached yet during the recursive descent. When visiting a GraphQL AST node, each visitor has ready access to the location of all information it will need upon final execution but need not concern itself with processing child nodes itself; a non-colliding naming convention for the AstMap’s keys is straightforward given that GraphQL AST node addresses are unique, which allows for a convenient look-up table to feed into some root AstFunc that processes the finalized translated ASTs. Allows for separation of concerns and abstracts away the recursion.)
We are currently working on supporting custom logic within the /graphql endpoint. This would allow you to fetch/resolve certain fields of your GraphQL schema from remote HTTP endpoints (which could also be GraphQL endpoints but don’t necessarily have to be). Would something like that work?
