Considering dgraph, have some newbie questions on if it makes sense for this use case

I find graph databases fascinating, but they are still a kind of unnatural way for me to approach a problem, so I’m not sure if it makes the most sense for what I am going to be building. This is essentially an insurance billing system that has a variety of one to many and many to many relationships, so essentially:
Patients
Centers
Insurance carriers
Diagnosis
Treatment
Billing
Collections
etc.
So a patient can have ‘n’ number of insurance carriers, diagnosis, treatment, etc.
A center can have ‘n’ number of patients and work with ‘n’ number of insurance carriers, etc.
Insurance carriers can work with ‘n’ number of patients and centers, etc.
you get the idea.
Then there is a lot of paperwork that gets attached to a patient, usually PDF files, that will follow them around.

In my limited experience with a graph database, it seems like it might make more sense than a typical relational database. What do you think?

Secondarily, I’m looking at languages. I’m considering WASM using golang or possibly Dart (there are reasons I need to focus as much as possible on Google technology). Is this feasible?
Thank you.

Hey @smga3000

Welcome to the coziest graph database community on Earth.

I agree with you that with the data you described, a graph DB makes a lot more sense than your typical relational database.

As a 10+ year user of Go, stick with Go :slight_smile: … but that’s my biased response. I do code in several other languages (Haskell, Ocaml, Rust etc), but time and again, I come back to Go. Something about the simplicity of the language that stops you from architect astronauting and just getting shit done.

4 Likes

I’m definitely a big fan of Go and have done some basic WASM tests with it and was pretty happy. This needs to run in a web browser, so I want to be as modern, maintainable, simple and scalable as possible, not to mention fast :slight_smile:

Alrighty then - let me know if you need help. I’m pretty new to dgraph myself (and graphql too), and we could always learn together.

1 Like

is anyone accessing dgraph through WASM or Dart that you know of? I don’t know how the api libraries for dgraph work exactly.

Hey @smga3000,

@CosmicPangolin1 is using Dart.

1 Like

Awesome, I’d love to connect with @CosmicPangolin1 to get some tips when he sees this :slight_smile:

@smga3000

Haha yes I am. I totally love Dart…I started coding with Flutter + Firebase, and I spent a lot of time learning language and architecture concepts through the Flutter and Dart GitHub threads (specifically from Erik Ernst, Bob Nystrom, and Ian Hickson). And while I now use Rust/JS/Ruby and all the acronym databases for a consulting dole I remain a huge proponent of Dart + Dgraph for most modern apps (I’d prolly prefer Rust for a raw performance concurrent system like Dgraph, hehe…and unfortunately Python for ML) :slight_smile:

There are several reasons, but the first one is really sufficient: Flutter and Dgraph are the tools that provide the highest incremental leverage in app architecture. In fact, both are epochal shifts in their category.

For UI/UX, Flutter provides true platform independence by efficiently shifting component rendering into client code. This has many positive consequences - including drastically increased expressiveness (eg. animations) and platform independence without sacrificing performance. That’s several obvious turns of leverage already - not only can I condense my app to one code base, but I can tackle designs that other people can’t handle with their tools.

For databasing, Dgraph + GraphQL allow you to fully represent your data with an elegant schema and traverse relationships such that you can query with any imaginable specificity. A good GraphQL database can handle anything enabled by NoSQL or SQL, but also substantially more. The other two are strictly constrained, both in query expression and performance, by the hacks they employ to ‘mimic’ the modeling of graph relationships…typically foreign keys and tight query constraints. Relationships are a core feature of data…in databases that don’t treat them like first-class citizens, you literally can’t even ask the right questions. God knows how much graph traversals increase leverage over time. The count of unlocked queries is proportional to data complexity, so it’s literally exponential when you’re thinking in complex social graphs :rofl:. Again, you can tackle designs other tools simply can’t handle.

These are huge deals, and I think their epochal significance is generally under-appreciated. People play technologies too safe in cases like this where relative leverage is heavily skewed towards one offering.

There are other reasons. Dart takes streams mainstream. The language’s performance improvement over time is impressive, and shows no signs of slowing down as they fold in new functional features and null-safety. It’s also really semantically clean - the team is great at choosing features to add and implementing them correctly. Thus it’s also great as a server language - and being able to build the majority of a company around one language is really, really nice.

The architecture patterns in Flutter emerging around streams are next-gen. Dgraph has insane raw-performance from excellent designs in Badger. All three communities are highly transparent projects with engaged communities. Etc, etc. :slight_smile:

2 Likes

Thank you very much for the great information. Let me know if you’re available for some short term freelancing as well :slight_smile:

1 Like