First of all, I want to thank you for creating this thread. No one asked you to, and you realize how important this thread is for some of your users. I realize I have been one of your strongest critics, but I only do that out of love for DGraph and frustration with lack of communication. Not getting a response is always worse than a negative response. That being said, I do hope you realize you have a team of people (including myself) ready to go to help promote, improve, and help you and DGraph as much as we can. Unfortunately, we are not GO programmers, but mostly front-end. However, there is a lot we can do when we get to that point. Just give us the word and we can help with things like Documentation, building demos, testing, etc… free.
I disagree with the fork entirely. I’m not even sure what that would solve. The fork (the direction you decide NOT to focus on), will just lose stamina and interest.
Pardon my candor here, I honestly don’t mean to offend. I don’t believe the TYPE of database is the problem at all. Graph databases are perhaps the most powerful database there is for queries. If DGraph goes to the dirt, another Graph database will eventually be seen. Firebase is the worst noSQL database I have seen as far as features etc. It is just a plain terrible database. Mongo now has features that make it usable, but I would use DGraph in its current state any day before I would use Firebase (Firestore) for a professional project.
The problem is NOT the database, but the marketing.
I have thought about this a lot.
With the right marketing, you should be saying things like “the FIRST fully functional graph database full end platform.” DGraph right now as it stands does things no other Graph database can do. It is self-hosted. You cannot use neo4j without spinning up your own custom middleware. It is not ready-to-go.
DGraph is 100% unique in so many ways. As I have said before, you only have a few real competitors on the front-end dbaas market.
- MongoDB Atlas
- FaunaDb (their FQL, not GraphQL)
There are NO real other competitors that are ready to go out-of-the-box. Even most mySQL providers require you to write your own middleware.
That middleware (even at 80% and not 100% read-to-go), is fire. That being said, you ARE a graph database, which is what GraphQL SHOULD be using under-the-hood.
Stop apologizing for being the first Graph Database platform, and own it! Advertise both, use both, and develop both!
That being said, with limited resources, you must look at what is really important to develop, and what is not. For GraphQL, there are some things we can’t do without for real product:
- Field Level Auth
- Pre-hooks Triggers
- Custom DQL Mutations
These three things alone give us the tools to build our own work-arounds. If we can write our code in the schema or keep our current GraphQL nodes, it will not deter people from the extra work involved. Pre-hooks and Custom DQL Mutations both should be able to be written in less than a week. Field Level Auth is necessary for security, and the only complex feature we can’t live without. VERY necessary. All the other features (nested filters, facets, cascade issues, etc) can be worked out later, and right now with custom dql queries etc. You need to tighten up security big time, and allow us to write our own middleware if you don’t have the resources to do it.
I think you need to understand GraphQL is almost where it needs to be to compete with the big dogs. It is just not quite there. The Graph Database indexes and algorithms, however, may need a lot more love (I don’t know).
Don’t fork the project. Tighten up GraphQL, then focus on the core database for a while. If and when you see your userbase change, go back to GraphQL. Keep updating it here and there.
You think there are 50 feature requests, but there are only a few main concepts that Dgraph is missing. The stuff that has never been done before is for later.
Your true product IMHO is neither neoj’s competition nor Firebase / Hasura… it is a new Field. The FIRST GraphQL database as a service instant API, subscriptions, etc out-of-the-box!!!. @amaster507 has written 50 blog posts about the power of the @auth directive, which can’t be done in SQL on any platform. There are so many things DGraph is good at. Sell the product for what it is.
1.) When will v21.12 be released on the cloud?
2.) Where is the current market that are paying users?
3.) What market do you feel you’re missing?
I wanted to add there are two projects I honestly believe (with users help as well) I could build.
A Firebase like platform for Admins. It would be just like DGraph Cloud’s Data Studio, but you could C(R)UD the data as well with a simple UI. Again, no one cares about Firebase’s database, just the easy-to-use API and UI. I would create an npm package that would run on the developer’s machine, no docker needed. I know this was sort of the plan for Data Studio, but you could focus more on the database issues.
I believe things like this could really help out. So I think you’re wrong when you say there is nothing you all can do. That being said, I don’t want to invest my time into building something like this (which I would enjoy doing), unless I am sure DGraph is going to exist in a year. So, keep us updated as soon as you hear good news (which you will).
P.S. Instead of changing your pricing model as @BenW suggested, perhaps you could just expand the amount of data transfer it can do to something realistic for testing purposes… just a thought.
P.S.S. @mrjn - I can’t give you motivation, but I can tell you “thank you,” from my nerdy heart, for the great product. I asked for it back in April 2020 jokingly on stackoverflow when I was trying to solve a Firebase Problem (— I started in mySQL btw), little did I know it was a possibility.