# Architecture

We have 15 servers, two of which are currently racked and online (the rest are in storage).
Each installed/racked server is configured with **128GB RAM** and **two Intel Xeon E5-2690v4 CPUs**.

One **FrontendMaster (FM)** server is dedicated to serving the actual website, managing user authentication, hosting the git repository service (`git.joyofhardware.com`), and maintaining the Nix cache. The remaining servers function as **Compute Nodes**, which leverage the git and Nix cache to support IDE sessions.

All servers are interconnected via a **40Gbps QSFP+ switch** with 32 ports, ensuring high-speed communication and scalability.

---

## Online IDE Inner-Workings

The Online IDE is designed to operate seamlessly on both desktop and browser environments. Below is an overview of the architecture and workflow:

### Compute Resource Allocation

- Each Compute Node houses **13 pre-allocated Docker containers**, configured to handle user IDE sessions.
  - **Container specifications**: 4 cores, 8GB RAM each.
  - The remaining 4 cores per node are reserved for **over-subscribed, single-core containers** (512MB RAM) to accommodate peak demand.

- Docker containers derive from the **NixOS Docker image** and are equipped with an **s6 Rust Actix-based service**. This service manages frontend requests for:
  - Language server completions.
  - File browsing and listings for the file pane.
  - Bitstream file handling (e.g., piping to WebUSB).
  - Real-time telemetry on CPU and RAM utilization.

### FrontendMaster Node Responsibilities

The FM server handles user session orchestration by:
1. **Allocating an IDE Session**:
   - Assigning an unallocated Docker container from the pool of Compute Nodes.
   - Monitoring container availability and spinning up replacement containers when needed.

2. **Session Initialization**:
   - Ensuring the user has a valid git repository on `git.joyofhardware.com`, containing required files (`nix.shell` and `default.nix`).
   - Establishing a websocket/tunnel connection between the frontend (FM server) and the container-side Rust Actix service for the user’s session.
   - Closing connections and destroying containers when users log out.

---

## Containerized vs Desktop IDE

For the desktop version (via Tauri):
- The container-side Rust Actix codebase will be modified to operate natively on the user’s desktop, supporting features like language servers and file management directly on local hardware.

---

### Vision for Scalability

- **Dynamic Scaling**: Containers are spun up on demand, ensuring optimal resource utilization. Idle containers maintain availability for new sessions.
- **Modular Services**: Rust Actix-based services enable efficient handling of language servers, file requests, and telemetry across a distributed infrastructure.

---