In 2014, we built a similar type event-driven system (but specifically for document distribution (a document can be distributed to a target set of entities; if a new entity is added, we need to resolve which distributions match)) and also ended up using Cypher via Neo4j (because of the complex taxonomical structure of how we mapped entities).
It is a super underrated query language and while most of the queries could also be translated to relational SQL, Cypher's linear construction using WITH clauses is far, far easier to reason about, IMO.
EDIT: feel like the devs went overboard with the mix of languages. Shoehorned in C# Blazor? Using JS and Jest for e2e testing?
So it may be the case that we'll see more Cypher out in the wild.
[0] https://cloud.google.com/spanner/docs/graph/opencypher-refer...
MATCH (p:Person)-[r]-(c:Company) RETURN p.Name, c.Name
So I'd say that linear queries are one of the things I like about Cypher, but the clean abstraction of complex `JOIN` operations is another huge one.
> but as soon as you need to join non-linearly
Perhaps a characteristic of our model (a taxonomy of Region, Country, Sponsor, Program, Trial, Site, Staff for global clinical trials and documents required by Region/Country/Program/Trial).
And then there's this:
> Installing Drasi in an EKS cluster can be significantly more complex than a standard installation on other platforms. Instead of downloading a CLI binary using the provided installation scripts, this approach requires modifying the source code of the Drasi CLI and building a local version of the CLI.
Is this an actual requirement or just the current easy path?
Assuming they choose this name from the Greek δράση which means action, React of course is the exact opposite to action, thus the React-ion; an action expects a reaction, somewhere somehow!
As for other stuff, it's using Gremlin Query Language or Postgres which are both open. In fact, it's going out of way it's not to use Azure authenication as loading connection string as Kubernetes secret is 100% AGAINST Azure Kubernetes Best Practice. Best Practice would be Workload Identity.
None of these words are in the Bible.
… and «-[r]-» can represent any relationship direction, which obviates the need for constructing separate queries for inverse traversing relationships. Kinda like running a compiler forward and backward.
https://www.oreilly.com/library/view/designing-data-intensiv...
Time will tell if Drasi is going to go the path where it becomes more easily useable outside of Azure (and in this case AWS) or it’ll go more of a Bicep route.
Also the only cloud provider it has installation instructions for is AWS's EKS platform. Yet it has integration instructions for Azure CosmosDb Gremlin API.
That one customer out there using EKS and Gremlin on CosmosDb is probably over the moon right now.
Taking a look at the Kafka docs [2] is also enlightening.
[1] https://www.amazon.com/Designing-Data-Intensive-Applications...
Perhaps most importantly, the book empowered me to talk confidently about the trade-offs involved with different choices of handling data, and gave me a language framework to talk accurately about those choices.
Previously even the parts I did understand was from experience, and not an academic background, so my explanations were hand-wavy or sloppy, but now I can state my case for different solutions much more clearly.
> "The Microsoft Azure Incubations team is excited to announce that Drasi is now available as an open-source project."
"Debezium", an alternative CDC system, is mentioned in the documentation and sources [1]. I'm not sure if Drasi uses Debezium, or aims to be compatible with it. Maybe someone here can shine more light on the relationship between these two?
--
1: https://github.com/drasi-project/drasi-platform/tree/main/re...
A bit similar how certain joins in SQL can be very straightforward with the "USING" clause, or when it can rely on extra information such as analytic views to derive materialized views (vendor specific)
https://babylon5.fandom.com/wiki/Drazi
But now I noticed the spelling difference :/.
The main current dependency is having a K8s cluster.
You can run Drasi for dev/test on k3s(https://drasi.io/how-to-guides/installation/install-on-k3s/) or kind(https://drasi.io/how-to-guides/installation/install-on-kind/) and docker desktop also works but is undocumented.
Cloud based options include AKS (we will release the instructions soon) and EKS as mentioned. When we tested on EKS, we hit some storage class issues and decided to publish this with some work-arounds instead of holding back until we do a proper fix, which we will prioritize if there is demand.
On prem K8s should also work, but we haven't put resources into testing those scenarios. We would love to engage with anybody that would be willing to try this out.
Also, in the future we are thinking about other delivery platforms, not just K8S. You will see in the code that our dependency on k8s is abstracted.
If you have any questions, the Drasi Team is most active over on our discord channel (https://aka.ms/drasidiscord) and we would love to answer your questions and help ypu get started using Drasi.
In the coming weeks we will get more of our Sources and Reactions documented as well as docs on how to create custom Sources and Reactions. In the short term, if people have Sources and Reactions they want so they can integrate with a wider range of up and downstream systems, we would love to help support their efforts in developing these.
The Drasi Team is most active over on discord channel (https://aka.ms/drasidiscord), where we are happy to answer questions and help people get started using Drasi.
Drasi docs are here - https://drasi.io/
The Drasi Team is most active over on discord, where we are happy to answer questions and help get people started using Drasi (https://aka.ms/drasidiscord)
People often use CDC to replicate, consolidate, filter, and transform data. And sometimes they use it as a source of change events to build components/services that look for specific data changes and do something when they detect those changes. This kind of components/services tend to be more complex to build, operate, and maintain than expected. Especially if they bring together data from multiple sources, have complex criteria, need to react in near real-time, be secure, and resilient. Most people that have had to build these can probably agree that they would like it to be less complex.
Drasi was created so people don't have to build this kind of component/service. They just write a Continuous Query (in Cypher), and then configure it to connect to supported Data Sources and Reactions (which do something when changes are detected).
Drasi manages the connection to the Source systems to get the low-level changes when they occur (sometimes using the Debezium library), maintains a perpetually accurate result set for the Continuous Query, and every time a source change results in a change to the Continuous Query result, Drasi generates a diff and sends it to the set of subscribed Reactions. The Reactions do something with those diffs depending on their purpose e.g. update a database, post an event, send an email, send a text message. All of this with no code in a platform that can scale to support many such queries.
There is more to it, but a good starting point is if you ever think to yourself that you want to query a database and then compare the results to a previous query result, and you want to do this periodically, you might consider Drasi as an alternative.
The Drasi Team is most active over on our discord channel(https://aka.ms/drasidiscord) and we would be happy to answer questions and help you evaluate whether Drasi is something that might be useful to you.
The project was announced through standard Microsoft channels by Mark Russinovich and is part of the Microsoft Collaboration on GitHub. But we are predominantly an open source project from the Azure Incubations team which has a history of releasing open source projects. So we don't feel the need to constantly remind everybody that we are a Microsoft project and team.
The documentation site is missing some content that wasn't ready in time for the release but it includes AKS install instructions as well as additional Source and Reaction docs. These will be out soon.
If you know that customer that uses EKS and Cosmos Gremlin, please let us know, we would also be over the moon.
In any case, the Drasi Team is most active over on our discord channel(https://aka.ms/drasidiscord) where we would love to answer any questions you have about Drasi and help you get up and running.
