How Dgraph Can Be Successful

Users Dgraph
1

Dear @akon and Dgraph Board,

Dgraph has been through a lot, but has chosen to continue. I thought I would offer my perspective on how it can succeed.

First some basic steps to get up and running:

Steps

  1. Get a team hired, posts updates WEEKLY to let everyone know where Dgraph stands.

  2. Spend 6mo getting up to speed and fixing bugs on v21.12. Release it on the cloud, after much testing. The community will be happy to help with testing. Continue to give weekly updates.

  3. Have a board meeting, release a roadmap of features, and talk about the future, what dgraph is, wants to be, and will be. Listen to the community, and continue to give weekly updates.

  4. Work on v22.X. This should be a small update, and include the following features:
    a. update-after @auth directive - enforce @auth update rule on the after condition. Update rules have a before and after state.
    b. pre-hook-lambda - triggers in neo4j and other databases have three options: before a query/mutation, after a query/mutation, and instead-of a query/mutation. Dgraph only supports after a query mutation. This would be the easiest way to allow field validation without creating a separate type, and would be easy.
    c. Fuzzy Full Text Search - with this, you don’t need elastic search etc to search the database. It should work in BOTH dql and graphql.
    d. Fix bugs with interfaces, unions, and enums searching, @auth not working etc… They should work in all cases as expected.
    All 3 of these features are some of the most requested easiest to implement with the biggest satisfaction - It will be the most bang for your buck, so to speak. By now, you will grow your team, income, etc. These features alone will get people excited again!

  5. Work on v23.Xa. This should concentrate on getting DQL up to par. Here the dgraph team should focus on math functions and loops. Then dql will be 99% awesome, and a competitor to neo4j!!! This is all that is required (ok, mostly…):

    • Loops
    • Math Functions - DateTime / String, etc
    • Work on redesigning docs for simplicity… there is a steep learning curve mainly due to the docs
    • Create simple howto videos on youtube like supabase, get Fireship’s attention for marketing

  6. Work on v23.Xb - This will be the most requested feature, nested filters This is perhaps the most important, but I feel that you can current get around most use cases with custom dql. This is a must to survive the graphql war! It should work equally on mutations, and deeply nested items.

    • nested filters
    • sort aggregates
    • field leve auth - similar to update after auth, but different… A field may need different access than the entire type (ex: role=admin… you don’t want a user changing that)
    • @auth rule based on external type - posts rules based on a user’s role in the database, in ex.
    • Composite id - something like this - ALTER TABLE `Bar` ADD UNIQUE `unique_index`(`user`, `date`); - @id on more than one field at once
    • Constraints - there are null and type constraints, but there should also be ways to enforce what goes into a database (slugs, date combinates, etc), but more powerful! These cover 99% of the security! With this, we can build RBAC for our users!
    • Subscription based on CDC
    • Subscriptions should use graph-ws - subscriptions-transport-ws is depreciated
    • Cascade Delete and Nested Updates - similar to sql to keep data integrity
    • allow graphql that is run in a lambda to not need a jwt. We need a version with jwt and without jwt to verify a user, or to act as an admin.
    • add Geo replication
    • create a plugin manager for dql to run complex data algorithms

Other Feature Requests to look at:

https://dgraph-feature-request.vercel.app/ - My Unofficial Feature Request Voting App!

What is Dgraph?

In case you don’t know, Dgraph is two very important things:

  1. A competitor to Firebase (not just Firestore) because it offers an affordable scalable cloud hosting solution with built-in middleware for frontend security, real time updates through subscriptions, and no configuration. There are only 3 current others that do all of these things. This is HIGHLY important for developer time. Prisma, neo4j, and MongoDb do not have all of these features.
    a. Supabase
    b. Fauna
    c. Hasura
  2. A competitor to neo4j - Scalable Graph Database marketing competitors
    a. Tigergraph
    b. ArrangoDB
    c. there are many others, but these are the ones we see on google

One day, when mature, it will be a competitor to postgresql and mysql, but way better. DGraph can make graph databases the norm for everyday users.

Dgraph needs to be both. Firebase and neo4j are a lot more alike than differences. The key to Dgraph is that it is potentially faster and scales better than neo4j, it is not a vendor-lock-in, and it has a beautiful middleware (graphql with @auth directive) to allow fast development. It will eventually offer file storage, and should eventually offer a built-in login system like auth0 or Firebase Auth. It should also have a javascript frontend client package to easily access the database if you don’t know how to configure graphql. Graphql is not easy to learn. Don’t worry, I wrote one for you.

So that is great and all, but what about our non-javascript users, self-hosters, and data scientists?
What you don’t know is that dql is already there. Do not waste time adding gremlin, cypher, or a new sql-like query language. Dql is already 90% there, and it has existed from the beginning. Do not start over and reinvent the wheel.

  • Math Functions, very basic, should not be too much programming individually:
  • Loops
  • Fuzzy Full Text Search

Once these features are built, dql will go from 90% to 98% complete.

Follow my roadmap above for getting Graphql from 90% to 98%.

Last but not least (or somewhere in between), make Dgraph cloud better.

  • Add the storage
  • Make data studio have CRUD functionality
  • Allow renaming types in the UI
  • Build an Auth System
  • Build a Client UI like Supabase / Firebase
  • Way later, add gremlin, cypher, new query languages etc.

There are so many things I left out.

Here are some more links:

  • State of Dgraph Now, and Lambdas – Notion:
  • Filed Issues:
  • Don’t try and be something that Dgraph is not.
  • Don’t waste time building anything new until what you have is where it should be.
  • Communicate weekly!!!
  • Listen to the spectrum of users from graphdb scientists to frontend devs and everything in between. Dgraph is 90% on both ends, but it can be so much better with small changes.
  • If you have questions, ask us! We are here and on Discord! Your faithful users. We support Dgraph, any forks, and other graph databases!
  • Dogfood your product! If you do not have several real functioning sites built with GraphQL, you will NEVER know what it is lacking. We are tired of theory, we want practice and practical! All your programmers should be required to build a SECURE website with Dgraph!

I am going to be using other products until we get some news and feel confident in Dgraph, but you guys know where to find me and the many others if you have any questions.

It is late for me, so I am done here.

I will be wishing Dgraph Labs the best,

J

8 Likes
2

Hi Jonathan (@jdgamble555),

Thank you for putting the time in to write down this post. I appreciate your input and time. You have put a lot of thought into it and I will use it as input to our roadmap development.

We are working on rebuilding the team at the moment (Step 0) and we are gradually getting ourselves acquainted with the different parts of the system. We have made slow but steady progress and the signs are encouraging.

I would like to have a direct conversations with you and other users/customers/community members to better understand your needs so that we can adjust our roadmap accordingly. I will make an announcement when we are ready to do this. At this point, what you have done with this post is the right way to bring things to our attention.

Thank you. Please stay tuned.
Regards,
Akon

8 Likes