Skip to main content

The Big Picture

This page is the map. It shows every moving piece in Dashify and the lines that connect them. The pages that follow zoom in on each piece in turn.

Read this once and the rest of the documentation will make a lot more sense.

What you are looking at​

The five tiers​

Reading the diagram top to bottom, Dashify has five tiers. Each one has a single, clear responsibility.

1. Browser tier, the experience​

The browser app is what your users actually look at. It is a React 18 application built with Vite, written in TypeScript, and shipped as a Progressive Web App. PWA means two things in practice: a small service worker caches assets so the app loads instantly even on slow connections, and the app is installable so users can launch it from their dock or home screen like a native app.

The browser app talks to the API over HTTPS for normal requests and over a WebSocket for real time updates (chat, notifications, board changes).

2. Edge tier, the gatekeeper​

In production a reverse proxy or CDN sits in front of the API. It terminates TLS, applies rate limits at the network edge, and serves static assets directly without involving the application tier. Locally this tier collapses into Docker's networking, the proxy is implicit.

3. Application tier, the brain​

This is where the work happens. Two processes share the same codebase but play different roles:

  • The API server answers every HTTP request and every WebSocket message. It runs on Node.js with Express, and every line of business logic flows through here.
  • The worker process picks up background jobs from a queue and runs them quietly. Sending an email, generating a PDF invoice, indexing a document for the AI assistant, sending a digest at 7 a.m., all of these are jobs.

The split is deliberate. The API must always feel fast, so anything that takes more than a few hundred milliseconds gets pushed onto the queue and handled by the worker.

4. Data tier, the memory​

Three storage systems back the platform:

  • MongoDB holds the documents, users, organisations, projects, work items, invoices, chat messages, everything. It is the source of truth.
  • Redis is the fast cache. It holds session state, queue payloads, rate limit counters, and the pub/sub channel that fans out real time updates across multiple API instances.
  • Qdrant is a specialised database for vectors, the numeric fingerprints of text the AI assistant uses to find relevant passages.

5. AI tier, the assistant​

A single container runs Ollama, the engine that hosts a small language model (Qwen 2.5, 1.5 billion parameters) and an embedding model (nomic-embed-text). Together they let the platform answer plain-English questions about the user's own documents, without anything ever leaving the deployment.

And, threading through everything: observability​

Every tier emits logs, metrics, and traces. Pino captures structured logs. Prometheus scrapes metrics. Grafana visualises them. Jaeger collects distributed traces via OpenTelemetry. Sentry catches uncaught exceptions in production. None of these are optional, they ship as part of the stack.

How a single request flows​

To make the diagram concrete, here is one request: a logged-in user clicking "Save" on a project board.

That single click touches every tier. And every step is observable, audited, and tenant scoped.

Why this shape​

A few questions might be on your mind:

  • Why a separate worker? Because the API must stay fast. If sending an invoice email took two seconds, the user would feel it. The worker absorbs slow work so the API does not.
  • Why Redis on top of MongoDB? Because MongoDB is great for storing documents but bad for things like "is this user trying to log in too many times in 60 seconds?" Redis is purpose-built for that kind of question.
  • Why on prem AI instead of an API? Because the user's documents are private. Sending them to an external service is, for many customers, not acceptable. Running the model locally keeps the data in-house.
  • Why MongoDB instead of Postgres? Because Dashify's data is heavily document-shaped (work items have nested labels and watchers; invoices have nested line items) and the schema evolves rapidly. Mongoose plus discriminated subdocuments fits the domain.

Where to go next​

  • Tech Stack, the exact packages used at each tier and why.
  • Multi-Tenancy Explained, the most important architectural rule and how it is enforced.
  • Database, a deeper look at MongoDB and Redis as Dashify uses them.

Key takeaways​

  • Dashify is five tiers: Browser to Edge to Application to Data to AI. Observability sits across all of them.
  • The API and the worker share code but play different roles: fast vs. patient.
  • MongoDB stores the world; Redis handles the fast questions; Qdrant holds the AI vectors; Ollama hosts the local LLM.
  • Every request is tenant scoped, RBAC-checked, audited, and observable.
Last updated on