Skip to content
evermeet 🔥 docs

System Architecture

We are currently developing a reference implementation @evermeet/evermeet. This implementation is written in JavaScript, and executed using Node.js, Deno or Bun runtime environment.

Future plan is to create implementations in other languages such as Rust or Go.

Evermeet Instance

Evermeet Instance is the term for an application that contains both a Backend as an API and a Frontend for clients.

Evermeet Instance diagram

Backend (api)

The backend is the central part of an evermeet instance:

  • handles most of the workflows
  • connected to the Database where the data is stored
  • communicate with the Frontend and clients
  • communicate with other instances within the Federation

Backend source code: @evermeet/api

JavaScript Runtime

Backend is runtime-agnostic, supports all major server-side JavaScript runtime environments: Node.js, Deno and Bun.

HTTP & WebSocket API

Backend communicate with Frontend, clients and external instances through HTTP & WebSocket API (XRPC) endpoints defined by Lexicons.

HTTP frameworks

Due to the runtime-agnostic approach, the use of various web frameworks is currently available:

Database

As a database, we currently use the storage-agnostic solution MikroORM.

Storage that can be used:

Frontend (web)

The web user interface through which users interact with the evermeet instance.

The frontend is written as Single-page Application (SPA) using SvelteKit powered by Svelte and Vite. For the communication with the Backend the HTTP API (XRPC) is used.

The frontend supports all modern standards including support for Server-side Rendering (SSR) for legacy browsers, bots and faster loading.

Frontend source code: @evermeet/web

CSS/UI Tools