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:
- Dgraph Cloud manages many components (db, GraphQL API, lambdas, some level of auth…) out of the box. Move fast.
- Incredibly fast to create and modify your (GraphQL) schema (speed of modification important for the world of frequently changing MVPs) including auth rules in that schema.
- Auto-generated GraphQL API. Move fast.
- Extend GraphQL API to handle external API data (ie, use Dgraph Cloud lambdas to call external APIs that your GraphQL API accesses/triggers.)
- Extend GraphQL API by using Dgraph Cloud lambdas to calculate GraphQL API fields
- Extend GraphQL API to do more involved graph db things by integrating your GraphQL API with Dgraph’s DQL
- If your MVP is focused on the relationships between data objects, not just focused on the objects themselves, then the underlying graph db may be a better fit (vs solutions that use a relational or doc-based database)
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.”)