Is Dgraph GraphQL ready for complex project?

[AugustDev]

We’re considering starting a complex project with MVP dev time 6-9 months. I’ve been looking at DGraph GraphQL docs and I like it a lot. However, as you all know real life often presents edge cases and other complications. I’m trying to figure out if we could actually save time using Dgraph GraphQL.

If you built complex project using Dgraph GraphQL would love to hear how did you find it?

[amaster507 (Anthony Master)]

Busy tonight and tomorrow, but ask what specific questions you have. I probably have one of the more complex applications built on top of Dgraph from the community and have learned a lot along the way. Do you want to know what to look out for? What are the edge cases? What are the security concerns? What are the learning curves? What specific teck stack are we using… so many details that I could write my word limit on just one post about all of this.

What are your concerns right now?

What are you struggling with?

Can you describe any more what you are trying to build?

And for chit chat with other Dgraph Devs, check out this unofficial Discord:

Join the Dgraph Users Community (unofficial) Discord Server!

We have talked this week and have started setting up some of these gotchas and edge case limitations to help others learn about Dgraph and chat about their dev process.

[hellohello]

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.”)