Skip to content

Xavier Backend Project – How It is Organized

Xavier.Backend Pocketbase.Go Temporal-Service.Prototype.JS Strapi

Xavier.Backend at a Glance

Location: https://git.icvr.io/icvr/xavier/backend/xavier.backend

The repository is structured into several key sections:

  • Services (the running backend components)
  • Shared code (libraries used by multiple services)
  • Dev tools
  • Scripts (verification, MR and helper scripts)
  • Legacy leftovers (planned cleanup)
Folder Tree Layout 
.
├── scripts ...                               # commit / formatting / license verification scripts                             
└── src                                       # backend services + Dockerfiles         
    ├── PBAC ...                              # PBAC Agent (policy evaluation)
    ├── aspire ...                            # local development environment (deployment using Aspire framework)
    ├── old-projects ...                      # legacy code from Wall-e, not used
    ├── services                              # backend services
    │   ├── devtools
    │   │   └── ICVR.Xavier.DevTools
    │   ├── gateway
    │   │   └── ICVR.Xavier.GatewayApi
    │   ├── notifications
    │   │   ├── ICVR.Xavier.EmailSender.Data
    │   │   ├── ICVR.Xavier.EmailSender.Domain
    │   │   ├── ICVR.Xavier.EmailSender.Grpc
    │   │   ├── ICVR.Xavier.EmailSender.Services
    │   │   └── ICVR.Xavier.EmailSender.WebApi
    │   ├── pbac
    │   │   ├── ICVR.Xavier.PolicyVault.Data
    │   │   ├── ICVR.Xavier.PolicyVault.Domain
    │   │   ├── ICVR.Xavier.PolicyVault.Services
    │   │   └── ICVR.Xavier.PolicyVault.WebApi
    │   ├── telemetry
    │   │   ├── bots
    │   │   ├── enrichment
    │   │   └── quotas
    │   ├── users
    │   │   ├── ICVR.Xavier.Users.Data
    │   │   ├── ICVR.Xavier.Users.Domain
    │   │   ├── ICVR.Xavier.Users.Grpc
    │   │   ├── ICVR.Xavier.Users.Services
    │   │   └── ICVR.Xavier.Users.WebApi
    │   └── workflow
    │       ├── ICVR.Xavier.Workflows
    │       └── ICVR.Xavier.WorkflowsImpl
    ├── shared ...                             # common libraries, models, integrations, proto files
    ├── tests ...                              # partial test coverage
    └── workers                                # services that manage the project's main storage and model registry 
        ├── assets
        │   ├── ICVR.Xavier.Assets.Data
        │   ├── ICVR.Xavier.Assets.Domain
        │   ├── ICVR.Xavier.Assets.Services
        │   ├── ICVR.Xavier.Assets.Services.Tests
        │   ├── ICVR.Xavier.Assets.WebApi
        │   ├── ICVR.Xavier.Assets.WebApi.Tests
        │   └── ICVR.Xavier.Assets.Worker
        ├── generation
        │   └── ICVR.Xavier.Workflows.Worker
        └── model_registry
            ├── ICVR.Xavier.ModelRegistry.Data
            ├── ICVR.Xavier.ModelRegistry.Domain
            ├── ICVR.Xavier.ModelRegistry.Services
            ├── ICVR.Xavier.ModelRegistry.WebApi
            ├── ICVR.Xavier.ModelRegistry.WebHook
            └── ICVR.Xavier.ModelRegistry.Worker

Top-level folders

scripts

The scripts folder contains various verification scripts for the project.

These scripts include:

  • Scripts for commits.
  • Verification scripts for checking licenses.
  • Scripts to verify that there are no "special left characters" in each commit, as formatting is supported.

src

Contains the main backend services plus the Dockerfiles used by DevOps/CI to build them.

  • Each service has its own Dockerfile
  • Dockerfiles are mostly straightforward, but include some workarounds related to C# tooling/security scanning in the build pipeline

PBAC

The PBAC (Policy Based Access Control) Agent is a separate service agent written in Go.

Its primary functions and characteristics are:

  • Rule Interpretation It contains an interpreter for the Polar language. This interpreter is used to evaluate rules and determine what actions users are permitted and forbidden to perform. The interpreter itself is implemented in Rust as a plug-in library, for which bindings exist for Go, leading to the decision to write the agent in Go.
  • Workflow When launched, it requests all available rules via a REST API call to the PBAC Vault (a separate rules repository service). When the Gateway sends a request for a user action, the agent runs the Polar language logic to confirm the user's permission.
  • Quota Checks It makes requests to other services, such as Telemetry, to find out current user quotas (e.g., whether money or space has been spent) to determine if a call should be made or if the user should be sent to pay for a new tariff.
  • Related Code An additional library for accessing the PBAC Agent via web calls, written in Go, is located in the AcL folder within the Shared directory.
  • Repository Status There is a Gitlab repository named "Xavier PBAC Agent," which is currently empty, where the agent might be moved in the future.

aspire

The Aspire folder contains the Aspire AppHost model — code‑first definition of app topology and resources used by the Aspire deployment framework. Its purpose is exclusively for local development.

The folder's functionality allows a developer to:

  • Raise all services and all containers in a linked, configured structure.
  • Start the entire project with a simple button, without needing deployment or additional setup.

This makes it so a developer can start working immediately without complications related to setting up the environment.

old-project

Contains legacy Wall-e projects. Not used by the current Xavier backend, intended for cleanup/removal.

services

Contains core services described below in a separate section.

shared

The shared folder contains all the shared assemblies that are used by all services in the project. It functions as a utilities folder for components that are necessary across the project but do not fit elsewhere.

The contents of the Shared folder include:

  • Basic APIs, common functions, common models, and common services.
  • Utility functions for accessing key components such as Pocketbase, Temporal, and KeyCloak.
  • gRPC Protobuf files.

Additionally, the folder contains the AcL subfolder, which holds an extra library written in Go for accessing the PBAC Agent over HTTP (used by services that need access control decisions).

tests

Tests exist, but coverage is limited:

  • Added mainly when issues/bugs appeared
  • Present in the pipeline configuration, but often run manually from IDE
  • Covers only some core paths (not a full safety net)

Core Services and Utilities

These services and utilities are located in the services folder.

Devtools

A lightweight developer utility for the Xavier backend that lets you:

  • Seed synthetic telemetry data into ClickHouse for local/dev use.
  • Publish synthetic domain events to Kafka (e.g., XUMI generation complete).
  • Check service health and explore APIs via FastEndpoints, Swagger, and ReDoc.

Gateway

The Gateway is a core service in the project that acts as the shared REST API.

Its main responsibilities are:

  • Request Flow Management The entire request flow passes through the Gateway, and it directs requests to all other services.
  • Quota Control It includes the direct implementation of PBAC (Policy Based Access Control) to control user quotas. This involves checking if a user is permitted to upload a file, whether they have available space remaining, and if necessary, whether payment has been made.

Notification service

The Notifications service is a relevant component of the project that is not currently in use and no active development is taking place. The plan is to "reanimate it" when real users are onboarded to send various IDs to user mail. The service is independent and does not depend on any other services.

PBAC Vault (rules repository)

The PBAC (Policy Based Access Control) Vault, also referred to as the "police vault," is a dedicated service that functions as a repository for storing all rules.

Key functions and interactions:

  • Rule Storage It is responsible for storing all rules needed to process user requests, including details on path permissions and whether to take user quotas into account.
  • Service Interaction It provides a REST API that the PBAC Agent uses to retrieve all available rules upon launch. It simply provides the rules and does not actively work with the agent.
  • Access It has a running REST API Web server and can provide rules to other recipients besides the PBAC Agent, such as the admin panel.

Telemetry Service

The Telemetry service is comprised of two parts and is designed to manage monitoring and user quotas:

1. Enrichment Service

The Enrichment service is responsible for gathering data to calculate the cost of running models.

It listens to Kafka channels for telemetry events related to model launches. When a launch message is received, the service accesses Prometheus to retrieve enriched information on GPU/CPU load and memory consumption. This information is collected and then written to ClickHouse.

The collected data is used to understand the load on models for technical optimization, such as deciding how many resources to allocate.

It is not currently used but is planned to be activated after the models are launched.

2. Quota Service

This service was intended to track the current quotas for users, such as money or space spent. The team will likely abandon this dedicated service in favor of using a simpler library that interacts directly with ClickHouse to retrieve necessary quota data.

The PBAC Agent uses the Telemetry service to find out a user's quotas to check if they can perform a requested action.

Additionally, there is a bot that generates events for viewing graphs in Grafana.

Workflow folder

The WorkFlow folder contains a single global project that is not considered a service, and its purpose is to document and manage all workflows in the Temporal system.

Key details about the Work Flow project:

  • Content It contains the definitions for all workflows and activities within the project.
  • Purpose It acts as documentation to help developers understand the many workflows that exist and to ensure they can call any workflow in a normal way from each service. Without this project, it would be easy to get confused by the large number of separate workflow and activity files.
  • Maintenance The definitions for these workflows are created manually. This is described as "a very big and painstaking, incredibly necessary work".
  • Implementation The definitions allow workflows implemented in languages like JavaScript, Typescript, or Python to be called or implemented in .NET if needed.

Workers Folder

Assets service

The Assets service manages the main storage for the entire project.

Key functions and characteristics of the Assets service:

  • Storage Management The service manages the main storage, which is located on S3. It can also work with S3-compatible repositories.
  • Actions The service is primarily responsible for functionality related to deleting files.
  • Asset Access It provides a URL for downloading assets.
  • Quota Control It integrates with the Gateway by adding direct PBAC (Policy Based Access Control) checks to control user quotas, such as checking if a person is allowed to upload, if they have space left, or if they have paid.

Model Registry Service

The Model Registry Service is a core service responsible for managing the models used in the project.

The service collects and stores metadata required for loading and starting the models. It stores all model manifests in Harbour containers.

The Xavier Workflow service interacts with the Model Registry to get data from the manifest, which is used to configure a model before the Workflow service retrieves the container directly from Harbour and launches it. When a new model is "spun into a docker" by an engineer, and all its parameters are not fully known, the Xavier Workflow runs the model in a test version to extract a manifest. This manifest shows metadata, such as how many resources the model consumes. The manifest is then sent to the Model Registry for internal validation and use in subsequent model launches. The model is launched in a non-working form on a host with minimal configuration purely to read the manifest.

Other Backend Repositories

The common backend project includes several other repositories:

pocketbase.go

Location: https://git.icvr.io/icvr/xavier/backend/pocketbase.go

Used as storage for cards, projects, user settings, and the portal/marketplace data. It includes custom edits for authorization, such as adding synchronization with KeyCloak to ensure uniform user IDs, as well as migration schemes and S3 settings.

temporal-service.prototype.js

Location: https://git.icvr.io/icvr/xavier/backend/temporal-service.prototype.js

Contains workflows and activities (Node.js) used for generating video, audio, and images by making requests to third-party providers (LLMs/neurons).

xavier.pbac.agent

Location: (https://git.icvr.io/icvr/xavier/backend/xavier.pbac.agent

Currently an empty repository where the PBAC agent might be moved in the future.

strapi

Location: https://git.icvr.io/icvr/xavier/backend/strapi

A legacy component from the 'Wall-e' project that is no longer needed but is carried along because the frontend still contains dependencies that have not been removed.