Deployment Strategy

Relevant source files

The following files were used as context for generating this wiki page:

• turbo.json
• README.md
• package.json
• apps/api/package.json
• apps/web/package.json
• packages/db/package.json

The deployment strategy for this monorepo is centered around two core technologies: Turborepo for high-performance build orchestration and Docker for containerization. Turborepo manages the build pipeline, ensuring that all applications (web, api) and shared packages (db, contract, ui) are built efficiently and in the correct order.

The project is structured to produce distinct, deployable applications from the apps/ directory. While specific production Dockerfiles are not detailed in the provided files, the use of a Docker-based DevContainer for development strongly indicates that containerization is the intended deployment method for production environments. This approach packages each application and its dependencies into a portable, isolated container.

Sources: README.md, turbo.json

Build Orchestration with Turborepo

Turborepo is the high-level build system that coordinates tasks across the entire monorepo. The root package.json defines scripts that leverage Turborepo's turbo CLI.

Sources: package.json:8-10

Build Pipeline Configuration

The core of the build orchestration is defined in turbo.json. This file configures the tasks that Turborepo can execute, defining their dependencies, inputs, and outputs to enable caching and parallel execution.

The following diagram illustrates the dependency flow for the build task.

This diagram shows that when turbo run build is executed, it triggers the build script in each application, which in turn depends on the build outputs of its package dependencies.

Sources: turbo.json

Key Tasks

The turbo.json file defines several key tasks for the project lifecycle. The build task is central to the deployment strategy.

Task	Description	Dependencies	Caching
build	Builds all applications and packages.	Depends on the build task of its package dependencies (^build).	Caches outputs in dist/** and .cache/tsbuildinfo.json.
type:check	Runs TypeScript type checking across the monorepo.	Depends on ^build.	Caches .cache/tsbuildinfo.json.
clean	Removes build artifacts and caches.	None.	Disabled.
dev	Runs applications in development mode.	None.	Disabled and persistent.

Sources: turbo.json:4-21

The build task is configured to depend on the build tasks of its dependencies (e.g., apps/api depends on packages/contract). It also includes .env* files as inputs, ensuring that builds are re-run if environment variables change.

"build": {
  "dependsOn": ["^build"],
  "inputs": ["$TURBO_DEFAULT$", ".env*"],
  "outputs": [".cache/tsbuildinfo.json", "dist/**"]
}

Sources: turbo.json:5-9

Application Build Processes

Each application in the apps/ directory has its own package.json with scripts that define how it is built for production.

API Application (apps/api)

The API application is a Hono server. Its build process involves compiling TypeScript source code into JavaScript.

• Build Command: tsc with-env
• Description: This command uses the TypeScript compiler (tsc) to transpile the code. The with-env part is a custom script that uses dotenv-cli to load environment variables from the root .env file before running the compiler. This is crucial for embedding build-time configuration.

"scripts": {
  "build": "tsc with-env",
  "dev": "pnpm with-env tsx watch src/index.ts",
  "with-env": "dotenv -e ../../.env --"
}

Sources: apps/api/package.json:4-8

Web Application (apps/web)

The web application is a React frontend built with Vinxi.

• Build Command: vinxi build
• Description: This command invokes the Vinxi framework's production build process, which bundles the React application, handles assets, and prepares it for serving. The output is typically placed in a dist or .output directory.

"scripts": {
  "start": "vinxi start",
  "build": "vinxi build",
  "dev": "vinxi dev"
}

Sources: apps/web/package.json:5-9

Containerization Strategy

The project utilizes Docker for creating consistent and portable environments. This is evident from the DevContainer setup, which provides a complete development environment, including a PostgreSQL database. It is the recommended method for getting started with the project.

The following diagram shows the components of the development environment managed by Docker Compose.

This diagram illustrates how the DevContainer encapsulates the application and its runtime, connecting to a separate database container. A similar pattern is expected for production deployment, where the built api and web applications would be packaged into their own Docker images and run as containers.

Sources: README.md:52-64, README.md:92-97

While the production Dockerfiles are not available for analysis, the README.md mentions their existence within the .devcontainer directory for the development setup, implying a container-first approach for the entire project lifecycle.

Sources: README.md:102-104