Ask Dgraph Founder Anything

Users
18

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.

  • Hasura
  • Supabase
  • Firebase
  • 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.

Questions:

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?

J

I wanted to add there are two projects I honestly believe (with users help as well) I could build.

  1. A Firebase / Supabase - like API that works on any JavaScript platform out-of-the-box. It would use URQL and GraphQL under-the hood. It could work in react, angular, svelte, vue, or vanilla js. This would not be hard to write, as I would use my easy-dgraph under-the-hood, support caching, subscriptions, etc. We would build the website for it, and make it work easily like Firebase and Supabase.

  2. 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.

6 Likes
19

Totally agree with the assessment. Most of the problems that GraphQL customers have are not super technical problems, they are ‘friction’ problems. IMO it seems that if Dgraph focussed more on onboarding, developer experience then developer adoption will take off.

DQL is crucially important for situations where you need a workaround. I think what needs to be done is to focus the docs on GraphQL, and cordon-off the DQL docs into an ‘Advanced’ section of the docs.

This is a great point, Dgraph is its own category (perhaps along with Fauna and Arango, which is graph-backed GraphQL generators), which is perhaps why it’s hard for a lot of new users (myself included …initially) to get why it’s so powerful. I imagine the most effective marketing strategy for Dgraph is not to market itself as a competing product in the GraphQL generator market, but best product in the subcategory of Graph-db powered GraphQL APIs or *Instant GraphQL API BaaS Tools".

Dgraph needs to focus it’s marketing on educating users on what this category of products is all about, i.e. why do we need our GraphQL APIs to be backed by Graph DBs? Why are the existing GraphQL solutions not good enough (and naturally why Dgraph is the best in the category). (I’m aware that Dgraph already does this, I just think it’s unfocussed).

I think part of Dgraph’s problem is that it markets itself as being in multiple categories, it’s in the category of “Graph Databases”, it’s also in the category of “GraphQL Generators” but really both these categories are saturated (meaning it’s hard to differentiate yourself). The right approach is to create a new category, and be loud about what this category is—this is how Dgraph makes it clear how it is differentiated.

Basically, it’s not clear to a lot of Hasura users why they should consider Dgraph. But there are a lot of people out there who:

  • Need GraphQL APIs that can handle complex relationships
  • Need a GraphQL API that delivers performance without endless tweaks
  • Need a GraphQL API that provides zero-config scalability

These are things that Dgraph is almost uniquely positioned to solve, however, it’s not obvious when you compare Dgraph to all the other GraphQL generators. These facts do become obvious when customers are educated about the fact that Dgraph is not in the same category as these other products, and you do that by marketing the category.

In the past I’ve said that the graph db aspect of Dgraph should be treated as an implementation detail in order to make the product less scary to web devs like myself who don’t have PhDs in computer science. But perhaps the actual problem is not that Dgraph is built on top of a graph db layer, it’s just that new users feel that they need to understand how graph databases work, and how to use DQL in order to use Dgraph (which technically they don’t).

Dgraph should be emphasising that the graph db is what makes it different, while at the same time making it clear that you get the benefits of this powerful graph database without having to learn Gremlin, Cypher and how graph algos work.

I think Dgraph needs to be more loud and opinionated about its belief that graph databases are the future of GraphQL APIs.

More about this:

4 Likes
20

YES!!!

However, that category should not be limited to just GraphQL, but anyone needing any front-end out-of-the-box powerful, zero-config, complex relationship building api!

I don’t think DGraph can compete as JUST a Graph Database, as there are many graph databases. It is SO MUCH better than that, people just need to see it.

This is your product.

A new category in itself…

J

3 Likes
22

@amaster507 – I’m not going to talk about the team here. As I mentioned, we had to do layoffs, and we got slammed on Glassdoor after that for various reasons – many of them were politically motivated to tell a version of the story. Also, remember that Glassdoor is an anonymous platform, anyone can write pretending to be anyone – there’s zero verification. So, I’ll take all that with a cup of salt.

Sorry, Anthony. I’ll have to delete your post. Let’s keep this to the technical side of things.

1 Like
23

But, honestly – are they? No GraphQL developer I have met has mentioned that they want a graph DB. Most full stack devs just want a Postgres. Most don’t even think that graph DBs are worth being a primary DB.

Dgraph has been extremely unique in its approach. It is not really a category, because other graph DBs don’t behave the same way (even if they have a GraphQL layer on top).

And IMO that’s the information overload that DQL creates. If Dgraph only supported GraphQL APIs, sure you might not be able to do “everything”, but it would be more approachable to most developers who just want to get their job done and go home on time. And if you look at the GraphQL spec, it has the same intentions – they kept it deliberately simplistic and approachable.

And that’s achievable without exposing DQL. I think if you want simplicity, you have to cut somewhere.

Docs are hard because there’re two different languages to tackle and two different deployment models (on-prem / cloud). If there was only one language and only one deployment model (like Firebase), docs would be more straightforward. Tutorials would all start the same way. Onboarding would be simpler and so on. You get the idea.

The more surface area is exposed, the more words, pictures, videos, tutorials need to be written to explain them.

3 Likes
24

My apologies sir.

Sure thing, so from your latest blog:

There are two major things I see here outside of the amazing :star_struck: performance boosts.

In this change, we also got rid of ludicrous mode, which was riddled with bugs. Concurrent transactions provide the same performance as ludicrous mode, while also providing strict transactional guarantees.

  1. So for users that were using ludicrous mode before, how do they do that now? Do they need to spin up multiple transactions? That always seemed like a nice feature even though it was “buggy” which was known from the beginning to not be 100% data safe anyways.

In v21.12, we have added a flag to forbid any key which has greater than 1000 splits by marking it forbidden in Badger. Once a key is forbidden, that key would continue to drop data and would always return an empty result.

  1. I understand this, but does this hence put a hard limit on the endless scalability of Dgraph?

I believe that types are stored as actual predicates so what happens when the predicate dgraph.type overflows? Do I stop having indexing on my types or maybe just a specific type? I assume this overflow would vary by the length of the value indexed and the size of the uids actually stored assuming that posting lists does not reserve 64 bits for every uid but rather just the size needed on disk.

Could this have been a problem recently discovered here:

1 Like
25

They don’t need to do anything. The flag is removed, IIRC, so perhaps config changes. All the writes should be faster by default, because we changed how transactions are run altogether.

There’s a flag which you can use to change the number. We set it by default to 1000. But, you could modify it as you need to. I strongly believe that any single key which has that many UIDs should NOT be served.

If one type has billions of nodes, then instead of using type(X), would be better to retrieve a field which only belongs to that type of node. Then check the existence of that to determine if the type is legit or not.

1 Like
26

This really concerns me and I think is a fundamental flaw with how types are handled/indexed.

Are types stored and indexed just like every other predicate and the type(Foo) is really only equivalent to eq(dgraph.type,"Foo")?

Are you up for discussions on how to make type indexing better?

It is possible that there is not any common field shared between all nodes of a type besides the uid, and I can’t get the whole galaxy with has(uid). So if all my nodes don’t share a common required field (required fields in DQL are mute points anyways) then how else could I get all nodes of any one type.

Will type function work after the galaxy is reduced? This is a BIG question. If I do happen to be able to reduce my nodes down to some other kind of has common predicate field, but that field is also shared across other types, would the type function work then, or would it always return nil from then on out? So if I grabbed a single node by uid, could I do a type check or not??

27

Boring. This has been done before, and frankly has a huge relational problem. Don’t get Anthony started on the n+1 problem. They don’t know what they want.

Again, most people don’t care about the database, they care about the interface and development time.

Uh… exactly!

So cut the development of DQL, and focus on the GraphQL, but don’t cut DQL out! I believe a lot of the missing features of DGraph’s GraphQL SHOULD be solved in DQL, not the top level (cascade delete, nested updates, constraints, auths, etc).

That being said, we are where we are… so close to a product that beats neo4j’s GraphQL out of the park (again, doesn’t work out-of-the-box), and Hasura’s GraphQL. The @auth directive is so powerful in DGraph… with a graph database under the hood, the complex filter problem is a thing of the past… just match Hasura’s functionality as GraphQL (90% there to Hasura… 80% the way there to compete with postgres’s full functionality) and you would knock ALL GraphQL out of the park… Hasura, Prisma, neo4j… all graphql api’s.

So, it seems you want to look in that direction, I just don’t think you need to fork.

Focus on GraphQL. I obviously have no issues with that (not everyone will agree). But you can have both over time, just don’t give up on both.

But, where is the current paying customers mostly? Where could they be? Those are still my questions…

Not related, but again, when should we expect v21.12 on cloud… about time if you’re not sure… since this is the question forum.

EDIT

This is really bothering me. Why would just get rid of more functionality. You SHOULD add custom dql mutations as well to the schema.

Even neo4j allows cypher, since GraphQL will ALWAYS be limited in and of itself. If you add certain GraphQL features, you should be able to build an app WITHOUT DQL, but don’t take away the option.

That is backwards!

EDIT 2

Firebase queries the collection, and can filter it with very little features. Not much of a language.

To be clear:

  • DGraph is Firestore’s competitor (not really Firebase) because of the easy api with subscriptions and cloud management (not the terrible noSQL database itself)… the name itself with API
  • DGraph is Hasura’s competitor because of GraphQL (a feature-rich graphql).
  • DGraph is neo4j’s competitor because of the Graph Database, and the availabilty of GraphQL, not the GraphQL middleware itself
  • DGraph is Supabase’s competitor because of the API and UI, not the database
  • DGraph is NOT really Mongo DB’s competitor, as you really can’t even do a basic follower feed in noSQL… worse in Firestore / Firebase RTDB
  • DGraph is a competitor for certain people who want to do complex Graph relations in a graph database

J

3 Likes
28

I have read in detail your other latest blog post:

It was so mesmerizing. Your engineering mind is exceptional!! :exploding_head:

The optimization improvements are terrific for a database that already touts ingestion speeds keeping up with major databases.

And then I saw the type problem, and you confirmed the problem with indexes. So, what if, types weren’t indexes, they were edges??

I can hear Chewxy correcting me already, that everything is already an edge, it is turtles all the way down. But please hear me out.

So sroar comes along and fixes the posting list problem. Not only with memory consumption but storage on disk, encoding/decoding, transmitting between nodes (Dgraph really uses the same terms for multiple meanings way too often) of the cluster.

Sroar has been optimized for the various intersection and union operations expected from RBs.

So let’s store types as a posting list. Let there be special edges that are types that store a posting list of uids that point to all of the nodes of the type.

Maybe under the hood even beneath DQL this edge would be named something that would be scoped into dgraph only like maybe even dotting notation the dgraph.type out further:

dgraph.type.User: [uid]
dgraph.type.Post: [uid]

And then using these bitmaps quickly retrieve all nodes of a type very very easily without hitting any indexes anywhere. No need to go through a big index tree of all the types to get a single type, just graph the single edge. This would in theory be the opposite of:

which uses some kind of reverse index I assume somehow with the has function.

Instead this proposal to fix types would be just like grabbing an edge. You could even internally in the datastore have a root node that then fans out to the types that fans out to the nodes. In DQL pseudo code:

{
  var(uid("0x1")) { # 0x1 is already reserved for GraphQL stuff AFAIK
    User as dgraph.type.User
  }
  queryUser(func: uid(User)) {
    id: uid
    username: User.username
  }
}

Fundamentally, these triples:

<0x2a> <dgraph.type> "User" .
<0x2b> <dgraph.type> "Post" .

would be rewritten to:

<0x1> <dgraph.type.User> <0x2a> .
<0x1> <dgraph.type.Post> <0x2b> .
1 Like
29

Type indexing does need to get better. But, more importantly, queries should be able to figure out the best way to check the type. This is not something users should have to think about.

I’ll skip the technical details for how it can be improved for now. I think this all falls in the general domain of query planning.

Thank you Anthony. You made my evening :slight_smile: . @ahsan did a lot of this work with me.

Agree.

:slight_smile:

3 Likes
30

Well, in my experience, most devs aren’t really attached to Postgres. They just use Postgres because:

  • Everyone else seems to use it
  • There are ORMs in every language that work with Postgres
  • They are familiar with it

This doesn’t mean that people don’t run into problems (like I did) and then look for alternatives. Ideally Dgraph should be educating devs on what these problems are—so devs for whom Dgraph is the right choice can avoid going through the process of building on Postgres only to realise that I should have just been using Dgraph from the start.

When devs say they don’t want to use a graph db that’s just due to misconceptions about problems that IMO Dgraph has actually solved. This is something I wrote about here:

I initially had these misconceptions and reservations about graph databases when I started looking at Dgraph. The only reason I didn’t bounce was that I had a strong incentive to dig deeper and figure out what this Dgraph is because using a relational db just wasn’t working. So I don’t think Dgraph necessarily needs to be something different, it just needs to emphasise the right things, and educate devs on how Dgraph will make your life easier, not just in technical terms but in terms of what life is like once you switch to Dgraph.

In practical terms that probably means deemphasising the graph db piece, and emphasising that Dgraph is a Backend as a Service, and the business benefits that come with using a BaaS. Dgraph should be more upfront about what problems it’s solving for users—right now most of Dgraph’s messaging is focussed on how it solves problems which draws attention to a lot of the scary complexity that devs are actually trying to avoid.

Another point to make here is that if devs truly cared about how the underlying persistence layer arranges data on disk, then the Firebase wouldn’t be a huge business. Because Firebase’s whole value proposition is “don’t worry about the data stuff, just build your app and we’ll give you an easy API”. Turns out that Firebase stores data in a proprietary document store format that leads to all kinds of problems. It’s only when devs start bumping up against the scalability limits of the database they are using when they really start thinking about this stuff.

Firebase has been around long enough that there are a bunch of mature startups running on Firebase who are bumping up against Firebase’s limits, which is the likely reason why there’s a growing number of ex-Firebase users looking for alternatives and talking about their frustrations. This is a fantastic opportunity for Dgraph to educate 1000s of frustrated Firebase devs on how Dgraph fixes all these problems they are having.

I’m optimistic that Dgraph is actually just really early in a new category of Firebase alternatives.

A category is more of an abstract marketing thing, it just how you present yourself to prospective customers. There’s all kinds of ways that Dgraph can categorise itself. Some are better than others, but the ideal way to categorise yourself is to find a way to create a new category. The category is just a mental framing that helps people understand how the product is differentiated.

For example, if Dgraph merely categorised itself as “a database” that puts it in the most undifferentiated category possible. If Dgraph categorised itself as “Super-scalable Backend as a Service” then it’s prompting the prospective user to compare it to any other products that feasibly fit into that category. The best category is one that is easy to grok, makes it clear what kind of product it is, but most importantly communicates that the product is a category that very few products have been able to achieve. It’s the difference between Usain Bolt categorising himself as “someone who is good at running” and “one of the only 156 humans in history who has been able to run 100m in less than 10 seconds”. I think currently Dgraph puts itself in some impressive categories, but it’s not spelled out for people—it’s only after doing a lot of reading that you realise that oh… all this technical stuff they are talking about actually equates to “Dgraph is gonna make it possible for me to achieve huge scale without having to hire a team of $300k/yr engineers / Dgraph is gonna make it possible for me to ship product 10x faster / Dgraph is gonna allow me to side-step all the query optimisation problems I’m having”.

Let’s compare Dgraph’s homepage to Firebase (please don’t take offence at any of these criticisms!)

image
image1300×754 85.1 KB

These are the first things people look at on the retrospective homepages. There’s a stark difference. Dgraph describes what the product does, the main feature (it’s a GraphQL API). There’s a vague value proposition (build it right first time), not sure what this means.

image
image1618×928 90.8 KB

Firebase by comparison does not reference the technical implementation at all. The key message on the homepage is a description of a benefit (Firebase helps you be successful as a web developer). This is what devs care about, being successful. This is what Dgraph needs to be talking about—how Dgraph will make you successful.

10 Likes
31

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.

8 Likes
32

Agreed that it’s a hard problem to solve. I’m not a marketing expert, but I believe if you try to win at web-dev then you need an angle like “firebase, but better because you can actually query stuff”. But then you have to build the one-stop-shop - auth, data, functions, object storage, remote config/feature flags, analytics, app performance, etc. I agree that web devs don’t care (and sometimes don’t know) about the difference between different database engines - document, relational, graph, SQL, NoSQL, NewSQL… just give me data fast, reliably, and don’t make me write too much code. The database engine that drives it is just an implementation detail. Dgraph is the fastest, most queriable, most scalable data engine you’ll ever use! Maybe there is an opportunity to partner with other web companies whose missions are “a faster web” like Vercel or Cloudflare or Fastly. If Vercel includes Dgraph in their tutorials, you’ve got another stream of curious devs.

On the other hand, going after the graph DB market seems like a longer-term play. Again, outsiders view, but graph analytics and algorithms that people/companies in data science seem to shop for. Probably bigger contracts but also long sales cycles meeting the needs of big companies. Or maybe there is an ML niche to slot into.

One thing I’ll agree with that someone else commented on - don’t remove DQL or on-premise functionality and documentation. If it’s not the golden path you’re aiming for, just bury the documentation under an “Advanced” section. Let the cloud, graphql approach be featured in the documentation. Everything else should be harder to find and therefore less confusing.

As for questions, I have none. I’m a happy user.

5 Likes
33

About what VCs are we all actually talking about, what kind of VC was the one that did the last funding?

If we are talking about the kind of VCs who also ‘invest’ big cash into companies like Uber and WeWork, they MUST also invest big money into dgraph because dgraph is a much more better and more legit product, than Uber or WeWork. i dont understand why they dont want to.
The only thing that dgraph lacks in my opinion, besides of the docs who could be better and more noob-dev friendly, is the presentation/marketing

Please look at this video manish if Apple made Window Blinds - YouTube

2 Likes
34

VCs seeks popularity and opportunity for capital gain. Kind of usual and it is their money they are putting in risk. Even in the case of UBER which is deficitary for years, they do invest on it cuz it is popular. The factual value of a product isn’t how good it is. Is how popular it gets.

Just like the most famous(my personal opinion) Graph DB out there. It is famous cuz they put a lot of money and effort in the popularity of the product. Not the quality.

3 Likes
35

This is so good. In fact, that’s my biggest learning – The best product doesn’t win. Best marketing does.

Great marketing is a skill that’s really hard to find. Much harder than finding great engineers.

True.

3 Likes
36

First of all thanks for taking the time to do this AMA. I really think you and your team upped your game again in terms of communication and transparency.
Of course there are still many more questions and we now have a more clear understanding why transparency and communicated progress was lacking. You are currently at a problematic spot and trying to find a way to transition.

I would like to ask some questions in terms of Open Source.
How come you switched from Github Issues to Discuss? I think it’s currently very hard to track which issues and bugs are open within Discuss.
Do you plan on using any alternative tracking software?
Was your plan always to keep development inside the company and just put the code out there?
I may not be as professional as you are, but I’m sure there are small things that could be contributed by the community.

Overall I’m very happy with DGraph and I think you are very close to a product that could explode with the right marketing.

4 Likes
37

The idea was to consolidate the GitHub issues from the dozens of repositories over to one place – Discourse. But, I also acknowledge that many people have complained about that for a while.

No. That was never the idea. But, given we were VC backed, we had the money to hire engineers. The PRs from the engineers kept us plenty busy. Contributions from community took a back step. This isn’t ideal, but also isn’t unusual for a VC backed open source project.

I think community plays a HUGE role in any project. And we’d be supportive of contributions.

Here’s a poll.

  • Should we turn on GitHub issues for Dgraph?
  • Yes
  • No
  • Maybe

0 voters

5 Likes
39

this!!! +1
this also makes my heart cry - there are so many talented engineers out there with brilliant ideas, which will never get executed…

What is Dgraph lacking? - #8 by Juri I wrote here many things, I break them down now:

here’s a quick to-do what can be done imo:

  • website rebranding (just taking an example from firebase and supabase. I’d go with the supabase design-approach. dont waste much time on thinking about an own webdesign, just inspire yourself from competitiors nobody cares. BTW dont use wordpress. wordpress is cool and nice for blogs and websites, but just create the website with react please. that will be a little more work, but you can finetune everything, it will look 999999x more professional, and people will see that it is custom build (dunno why but people dont trust tech solutions that say they are high tech and awesome but didnt took some extra hours for building the website with react. using wordpress looks unprofessional (for a project I and my buddy used wordpress too and people on reddit hated us for using wordpress)))
  • realising it does not matter if dgraph is now a spanner killer, or a firebase killer, or something different… different people want to hear different things, so it’s ok and not unprofessional to just say
    “Hey dgraph is a super scalable backend as a service, with dgraph you don’t need Firestore neo4j Cloud Spanner Elasticsearch or Supabase anymore, we have everything you want to build, run, and scale successful apps in 2022 with every feature. What are you waiting for, dig now into our docs or our guid or our video tutorial and GO!” it’s ok to brag and actually mention other products, many do that, and tbh I even love that. I love it when a company makes an own comparisson of their product against another one Typesense vs Algolia vs Elasticsearch vs Meilisearch Comparison
  • Docs, please, we need better docs for noobs, the only reason I am here is because you answered my specific questions on reddit + i spend much time understanding and asking questions. Many people dont want to get active and ask questions around, they want to look into the docs or google, and find the questions with their answers. They want tutorials on youtube. Noob developers of today are the top engineers tomorrow. One approach is to split up the docs into 2 docs, into the docs how they are now (not much described/explained, but very good for quickly look up something), and docs who actually teach dgraph in depth, you can make them ridiculous long with many explanations examples and so on, people will just read them 1x and will use for look-ups the short docs.
    So you basically just leave the docs as they are, and create second docs where you write big romans with mannnnny examples so that even donkey kongs like me will understand everything without having any gaps.
  • contacting fireship, freecodecamp, netninja (all these awesome dudes that publish tutorials for free), and ask them if they want to make tutorial dgraph videos, and taht they can get your discord/skype/whatsapp/whateveryouuse and they can contact you with questions and you will answer them immediately (this makes it much easier creating quickly a video and understanding dgraph quickly with asking annoying questions like I did LOL but they won’t wait until someone on discuss replies, they want answers immediately to have the video done ASAP without wasting too much time)
  • making 1:1 the same video course just with dgraph Get to know Cloud Firestore - YouTube

this are really simple quick things you can get done within december! sum up:

  • completely new website built with react/gatsby/nextjs (without bugs, I contacted you guys via email cuz of a basic 404 bug and it was never fixed afaik (some weeks ago wasnt fixed yet))
  • starting to brag that dgraph is the backend/database with the biggest D in the room and make comparisons to every other backend/database product. just compare dgraph to mysql supabase firestore, nobody cares that you can’t fr compare these things. aggressive brazen bold marketing. if you tell people dgraph is the backend/db with the biggest D that can do everything better than anyone else, they are likely to give it a shot
  • extra docs for noobs plsssss
  • contact youtubers and give them your number/discord/facebook/whateveryouuse for immediately support (if you as the CEO give them a direct way to contact you immediately (email is not a direct way), they will appreciate it and know that you respect their precious time and they’ll therefore spend even more passion into presenting dgraph to the world since they know dgraph is not a project for you bot a passion, for which you are willing to give up private space/time. I suggest that you make with each youtuber an own whatsapp or discord group with the youtuber and you and all the other devs like dmail and daniel, so that if he has a question someone immediately replies to him. you can also add me and if the other guys Anthony gamble Koder want, also to the group)
  • making an own youtube video course. it’s really simple. you create a word doc, you write the content of each video + script, you speak the script into your mic, and then you create the video content. then you mix up everything together in premiere pro. I can give you via zoom/teamviewer assistant into cutting (some years ago I made videos, here’s one of it Redirecting... ) I can help you to make the videos feel more professional and easy to understand since I am a noob and have the view of a noob and can give you the feedback of a noob

that’s it. these are easy measures you can start today. this can polish dgraph extremely up imo

image
image875×779 78.4 KB

image
image678×1219 188 KB

https://www.reddit.com/r/dgraph/comments/pq8wcd/how_good_are_the_query_capabilities_in/

took me now an hour to write this (._.) gud night

3 Likes