DOCSEARCHbyAlgolia
Submit Docs

Drasi Documentation

website·Indexed 33 days ago

https://drasi.io

Documentation for Drasi, a platform for creating Continuous Queries to maintain real-time data views. Includes guides for installation on Kubernetes (EKS, k3s, kind), Docker, and the Drasi CLI. Features detailed references for the Graph Query Language (GQL), openCypher subset, custom functions, and middleware. Covers the configuration of Reactions such as SignalR, MCP, and Stored Procedures, as well as a VS Code extension for managing environments.

Tokens
142.9K
Snippets
725
Records
975
Agent score
69%

What's inside Drasi

  1. Overview of the Drasi Server Architecture Learning Path

    The Architecture Path is designed for architects to gain a deep understanding of Drasi architecture and design patterns for building solutions. The path takes approximately 2-3 hours to complete and covers the following core areas:

    1. Drasi Overview: High-level architectural big picture.
    2. Solution Design: Core design principles for reactive systems.
    3. Continuous Queries Deep Dive: Detailed look at the query execution model and state maintenance.
    4. Solution Architecture Patterns: Reference architectures for common deployment scenarios.
    5. Performance Patterns: Strategies for system optimization.
    6. Security Best Practices: Guidelines for securing Drasi deployments.

    Prerequisites include experience with distributed systems architecture and an understanding of event-driven and reactive patterns.

  2. Overview of Drasi's reactive data capabilities

    Drasi enables the creation of reactive systems by treating disparate heterogeneous data sources (e.g., PostgreSQL and MySQL) as a single virtual graph. Key capabilities include:

    • Cross-Source Joins: Using YAML configuration for connection parameters and 'Synthetic Relationships' in continuous queries to link data across different databases.
    • Declarative Queries: Using Cypher-style (openCypher) declarative queries instead of complex stream processing code (like Flink) or polling mechanisms.
    • Instant Reactivity: Pushing updates instantly (e.g., via SignalR) to dashboards as soon as underlying data changes, avoiding the latency associated with polling intervals.

  3. Overview of Drasi Server Core Building Blocks

    Drasi Server allows developers to create Continuous Queries that react to data changes without polling. It is composed of three core building blocks:

    1. Sources: Connects Drasi Server to data sources (e.g., PostgreSQL).
    2. Continuous Queries: Declarative queries that define which data changes matter.
    3. Reactions: Automatic actions triggered when the results of a Continuous Query change.

  5. Overview of Drasi for Kubernetes Operations Path

    The Operations Path is designed for DevOps and SRE professionals to learn how to deploy, monitor, and maintain Drasi for Kubernetes in production environments. The path takes approximately 3-4 hours to complete and covers the following key areas:

    • Deployment: Choosing installation options and performing production deployments (e.g., on Azure AKS).
    • Observability: Configuring metrics and tracing.
    • Monitoring: Setting up alerting and dashboards.
    • Scaling: Implementing strategies to handle production workloads.
    • Troubleshooting: Diagnosing and resolving common issues.

    Prerequisites include experience with Kubernetes, familiarity with observability tools, and access to a Kubernetes cluster.

  6. Overview of Drasi Server core concepts

    Drasi Server operates based on three primary components:

    • Sources: The origin of the data being monitored.
    • Continuous Queries: Queries that run reactively as data changes.
    • Reactions: Actions triggered based on the results of the queries.

  7. Overview of Drasi Source and Reaction Creation Agents

    Drasi provides four GitHub Copilot custom agents (located in .github/agents within the drasi-core repository) to automate the creation of production-quality Source and Reaction plugins. The process is split into two distinct phases: planning (research and specification) and execution (implementation, testing, and documentation). This separation ensures that implementation is based on a verified plan and a proof-of-concept rather than assumptions.

  9. Overview of drasi-lib in-process change detection

    drasi-lib embeds Drasi's change processing engine directly into an application, enabling real-time monitoring and reaction to data changes without requiring separate infrastructure. It supports Rust, Node.js, Python, and .NET. The system operates by creating Sources (to ingest changes from external systems like PostgreSQL/gRPC or internal state), Continuous Queries (to process those changes), and Reactions (to trigger external systems or update internal state).

  10. Overview of the Trivia Game Dataset architecture

    The Trivia Game Dataset uses a hybrid data model to represent an online trivia game consisting of Teams, Players, Questions, Categories, and Answers. The data is split across two different database types:

    • Graph data (Team, Player, Answer) is stored in an Azure Cosmos Gremlin database.
    • Relational data (Question and Category) is stored in a PostgreSQL database running within a Docker container.

  11. Overview of Drasi's Continuous Query model

    Drasi allows developers to write declarative continuous queries across a virtual knowledge graph that spans multiple heterogeneous data sources. Unlike traditional polling or complex stream processing (like Flink), Drasi maintains an always-current result set as data changes and can trigger actions (reactions) when those result sets are updated.