It’s possible that our platform could help with the funding issues. MIcroventures.com is a democratized angel investment platform with exposure to accredited investors.
We’re moving our entire platform away from MySQL into Dgraph. We’re in the early stages of doing this and hearing there are issues for the future of the platform has me hesitating in a big way.
What I see in Dgraph is the ability to unify my engineering team under Javascript and Graphql. All my core API functionality is handled by dgraph’s API replacement under the hood. That’s code I don’t have to write.
When my engineers are asked to add a feature, Say, “Present a list of the user’s last 5 posts”; In the old stack, either they have to query an existing API endpoint that would probably present far too much data and be inefficient, possibly prompting more work to overcome the inefficiencies like caching… OR, they’d have to make a request to the backend team and get on their schedule, to get a custom endpoint.
With Dgraph, the power of the backend team is transferred to the frontend team. My engineering team can focus on React and the presentation of the data. They can easily query and interact with the data without delays when that structure needs to be slightly different.
It also means that I can pivot off the dgraph types generated by Graphql Codegen and be confident that my application is functional across the board even when the schema changes.
But all of these advancements have come with a development cost.
- I have had to build a custom data migration tool as there doesn’t exist a good one on the market. This gives me the ability to have a versioned data migration when our schema changes.
- I’ve had to build a schema management engine so we can manage our schema within the codebase.
- The documentation and examples differ between self-hosted platforms and the enterprise SAAS platform.
- The official CLI’s (dgraph-js) work with DQL instead of Graphql. This makes it difficult to integrate directly with existing products.
IMHO, Dgraph has a ton of performance power for our engineering team. It has not been without its challenges to get our stack working with the platform, however we’ve solved most of those issues.
What I would love to see in the future:
- A focus on a seamless low-level developer onboarding experience.
- A focus on consistency within documentation.
- An official dgraph toolset for data and schema versioning that is manageable within our codebases.
Dgraph offers something that’s hard to find, efficiency, and cost savings in the engineering department. Play on that angle and re-double efforts to support the community and the engineers will evangelize the product.
I sincerely hope Dgraph is successful.