Is Dgraph GraphQL ready for complex project?

I think Dgraph can be a really good fit for some fast moving, “needs to be quickly flexible” mvps. And with the speed and flexibility of modifying your schema and your GraphQL API, you have a lot of flexibility to handle complexity. But there are other things to consider I think (see last list below.)

MVP Speed and Flexibility:

However, note:

  • No nested filtering on Dgraph’s GraphQL API like other GraphQL APIs provide (that are usually hooked up to relational dbs) (but a) you may find alt ways to query for those use cases and b) perhaps integrating DQL queries with your GraphQL may solve?)
  • MVPs are supposed to be quick and dirty, but if the end result product will use a significantly different underlying database (such as a relational db), I wonder about the pain of moving from graph db-built MVP to your final product? Though on the front end, if your final GraphQL API is similar to your MVP Dgraph GraphQL API, then your frontend wouldn’t need to change much perhaps.
  • Update: There may be some DQL limitations too that I’m at this minute working through (such as the recursive path building mentioned above may only look at 1 predicate to build that path and other limitations… and generally Dgraph does not seem to have prioritized the creation of what seems like a common graph db need: “Consistently return all the nested children of an unknown depth from source to leaves.”)