I think Dgraph is on the right track to be come a very popular solution. From what I can see (front end dev) there are a few things I can see that would make a difference:
- Provide a generous free tier. From experience most adoption of new technology comes from developers trying things out in their spare time / side projects, loving the tech, spreading the word, and then finally influencing their work to adopt the tech. If casual users have to pay a premium to explore the product then it makes the barrier to entry higher.
- Focus on creating a product for everyone, then improve / adjust it for businesses/enterprise. I understand that businesses using the product is where you will make more money, but it’ll be a harder sell to developers if it hasn’t already got a strong presence in the community. In the context of Dgraph this would be making the GraphQL features and Dgraph Cloud the best products they can be.
- Ensure the GraphQL features are equivalent (ideally better) than competitors. This includes making sure they have a similar (or better) way of working and syntax. Eg nested filtering, nesting aggregate query inside regular query etc.
- Invest in building a community, docs and industry related content. I think this going to the hardest thing to do as it needs to happen organically. Building a community takes time, engagement and an emphasis on the end users. I think Dgraph has a bit of work to make it more accessible. If I personally don’t have a good time using the product, I’m not going to suggest to my work (or other people) to use it and object if other people suggest it. In fact, I know we have made decisions at my work because the team behind the product was hard to work with, didn’t respond etc. It didn’t make a difference how good the product was.
- Have a strong product vision (this is very important). I think its ok to even have a couple. And this has to be clearly communicate publicly, ideally including roadmaps (or some other form of transparency). I would also make sure that the product visions have a clearly identified audience.
A few things on my wishlist (all for GraphQL):
- An out of the box local (offline) development experience (aka without me having to learn / do much). I have achieved this but it took a while, and was harder than it should have been. I had to spend time trying difference parts of the docs to get something working (ie with importing data, exporting data, updating my schema etc). A great example of what to strive for is Firebase’s local emulator.
- A way to batch mutations so I can roll back a group of changes. Something similar to Firebase’s transaction and batched writes.
- Nested filtering. This is very important to many parts of my projects.
- Be able to simply replace a list in a mutation. Currently I have to remove the items in the array and then fill it back up with what I want. Very annoying and not how any other garphql framework I have used works.
- To fix this bug - Removing edges using null does not work
I personally use Dgraph as my database. And I feel most people wanting to explore with it will do the same. However, I know this isn’t the case if I was to use it at my work. We would want to use as an interface for some of our databases, and if we liked it then maybe look at using it more as a database (if it made sense too).
I have also not really explored the DQL aspect of Dgraph. Mostly due to it (from what I can tell) not a transferable skill. If I decide to move away from Dgraph then I can take my GraphQL schema and all of my queries/mutations along with me (with some exceptions naturally).
All that aside, you have done a wonderful job @mrjn (and the entire team) in creating a very compelling product. Excited to see what’s ahead!