A graph database of course lends itself for a GraphQL transport layer. Are there any plans to integrate this? As you can see with DGraph, it would really help adoption and interest.
How so? TerminusDB has a vastly more powerful query infrastructure. Furthermore it’s architecture is far superior to GraphDB which is why I’m here. Give these guys a few more weeks/months and I think you will find that TerminusDB simply has no peer when it comes to persisting and querying rich semantic data.
TerminusDB uses JSON-LD, which is a serialization of RDF - no current plans to integrate GraphQL. The Dgraph folks have built a really powerful system, but their focus is different. They are ‘distributed first’ whereas we think you should avoid building distributed systems if you can help it. We’ve been working on the revision control features as we think that is a gap in current architectures - hopefully that helps grow interest.
Exactly! … “first principles first”
We actually did have a prototype GraphQL interface once - it mapped the document types defined in the schema to GraphQL endpoints with the schema mapped to GraphQL rules for validation. We didn’t pursue it because, as Brad notes - it was like playing basketball through a straw compared to the Query interface. As soon as WOQL came out, we threw away almost all the old APIs we had because we didn’t need them any more and never used them - there’s a whole bunch of WOQL that you can’t say with GraphQL filters and it restricts you to API style document-at-a-time or preconfigured list paradigms. We do have a new library interface for WOQL which is a little along the GraphQL pre-defined endpoint direction, but of course you can pass it woqls rather than strings