I’m building a tool for managing graph database schemas. Part of that is the ability to spin up a GraphQL API with a Dgraph backend - just from the GraphQL schema. GraphSchema does all the work of going from GraphQL endpoint to Dgraph query and back out again, so no code required to get a GraphQL endpoint.
Hope you have a look and like the ideas. There’s what’s in the video, plus lots more development happening at the moment. I’m sure you’ll pick some rough edges in there and features you’d like to see.
I’m expecting to have a demo out in Jan next year.
Your tools seems work great, as I looking for similar tool, I wonder what technique you use for query transformation ? I thinking about this flow
parse the GraphQL query, turn it into GraphQL query AST nodes
build DGraph query string by walking the GraphQL query AST nodes
And a bit question about decision to make arbitrary DGraph functions strings injectable to GraphQL query (Video #2 - time 4:37) , which I think dangerous if client can do that.
and last, what language you use for this tools, and is there any code you could share ?
Yes, the general approach I use is to parse the GraphQL and walk it’s syntax tree building up GraphQL± as I go. There’s also a bunch of checking off against the original GraphQL schema and inserting extra bits in the query based on both the schema and the query.
I’m intending to have a hardened demo to share sometime in the next month or two and am thinking about providing a service of hosted instances … so you don’t have to write your own
It’s a C# .net core app, so it runs on anything; and cause it’s stateless itself, it’s easy to spin up and scale in containers.
I agree that if you exposed the ability to inject arbitrary query right through to the backend that would expose quite some power to a client. But I wouldn’t do that. Think of GraphSchema as something like an ORM. An ORM, or other database mapping tool, gives you a mapping around your database that gives you a friendly API to work with as a programmer, but you wouldn’t expose that directly to a client, you’d build on top of it and expose that as a REST/GraphQL API that protects your data layer and enforces business logic etc.
GraphSchema is the same: it spins up a data layer for you and exposes it as a friendly API - you expose an API on top of it to your clients. If you know GraphQL well, think of GraphSchema as spinning up data microservices for you from schema definitions and you’d do schema-stitching, authentication, business logic, rate limiting, etc on top of that.
Hey Michael, great work, I would like to contribute on the project / help you as much as possible.
I need a tool like this for the project I am working on.
Thanks for the interest. I slowed down a bit with holidays over Christmas, but back on track now. I’m expecting to have a solid demo version released this month sometime. I’m also putting together a cloud hosted option. If you’d like to be an early adopter of either of those when they are ready, I would would value some users and feedback.
That’s a known issue. It’s because Dgraph by default returns all predicates as lists. I chose not to correct it yet because of this open Dgraph issue Support 1 to 1 associations at the schema level · Issue #2511 · dgraph-io/dgraph · GitHub. If that gets done, I think I’ll be able to support it with no work in GraphSchema, otherwise GraphSchema will have to do it.
At this point I just chose to wait and see what happens with that issue which is currently has a Jan eta on it.
One more question - will it be possible to use GraphSchema as an ORM-like module within my own API, or will it only be a server that stands in front of the database?
I would love to be an early adopter, and I am available to help you in any way possible in order to make it work the way you envision it.
I have experience in kubernetes and distributed systems in general if you need my help in the cloud hosted solution.
It presents as a GraphQL endpoint, so you’d access it as you would any other GraphQL endpoint. That can be something like writing a GraphQL server that stitches together some backend GraphQL services in its own resolvers (e.g. Apollo does it like this).
I’m building an API using it right now and I chose to do more like you are describing. I wrapped calls to the backend GraphSchema service in something that looks like an ORM with a simple query interface, so I can access the underlying services and object model easily. But it’s far from perfect.
Things like ORMs don’t really seem to be quite built out yet for GraphQL or graph databases in general. That’s some of the tooling that would be great. It’s the kind of thing that’s language specific so I imagine that tool kits to work with a backend GraphQL store through an ORM-like model will get built for various languages and that would be something to use on top of GraphSchema or any other GraphQL endpoint.
Hi, thanks for the interest. There’s nothing public yet. I’m just adding some features and test infrastructure and there’ll be something available in the next week or two.
It’s early stages and not broadly tested in lots of environments yet. I welcome your feedback.
Thank you to everyone who’s liked the original post and posted comments.
I’m intending to keep building out the tool and the testing infrastructure. I’m also thinking of offering a hosted service - e.g. you bring along just a schema file and the service manages all the infrastructure, replication, backups etc. That’ll also include the ability to host Dgraph instances as well. (should be an early access version, end of March(-ish) timeframe, I’ll let you know when you can reach out if you’d like to be given access to that).
