Deployment
Relevant source files
The following files were used as context for generating this wiki page:
The Ever Rec platform is a monorepo managed by Turborepo, containing three primary applications: a NestJS API server (api), a Next.js web portal (portal), and a browser extension (extensions). Each application has its own distinct build and deployment process. The project utilizes pnpm as its package manager and provides scripts for building each application for production environments.
Deployment involves building the individual applications and deploying them to their respective hosting environments. The README.md indicates that the platform is powered by Vercel and DigitalOcean, suggesting the portal is likely deployed on Vercel and the API on a service like DigitalOcean.
Overall Build Process
The root package.json uses Turborepo to orchestrate the build process for all applications within the monorepo. Running pnpm build from the root directory will trigger the build scripts defined in the package.json of each individual application.
This diagram illustrates the high-level build flow managed by Turborepo.
Root Build Scripts
The primary build commands are defined in the root package.json.
| Script | Description |
|---|---|
pnpm build | Builds all applications in the monorepo using Turbo. |
pnpm build:api | Builds only the API server. |
pnpm build:portal | Builds only the web portal. |
pnpm build:extensions | Builds only the browser extensions. |
Sources: package.json:19-22
API (apps/api) Deployment
The API is a NestJS application. Its deployment involves building the TypeScript source code into JavaScript and running the compiled output with Node.js.
Build
The build process for the API is handled by the nest build command. This command transpiles the TypeScript files from apps/api/src into JavaScript and places the output in the apps/api/dist directory.
- Build command:
pnpm build:api(which runsnest build) - Output directory:
dist/
Sources: apps/api/package.json:13
Startup
The production server is started using the node dist/main command. The main entry point is apps/api/src/main.ts, which bootstraps the NestJS application.
Key startup configurations:
- Global Prefix: All API routes are prefixed with
/api/v1. - CORS: Enabled for the
WEBSITE_URLdefined in environment variables. - Port: Listens on the port specified by the
API_PORTenvironment variable, defaulting to3000. - Body Parser: Configured with a limit of
50mb. - Static Assets: Serves static files from a
publicdirectory. - Swagger: An OpenAPI (Swagger) documentation page is set up at the
/docsendpoint.
Sources: apps/api/src/main.ts:12-61, apps/api/package.json:17
This diagram shows the sequence of events when the API server starts.
Sources: apps/api/src/main.ts
Portal (apps/portal) Deployment
The portal is a Next.js application. It is configured for deployment on a platform like Vercel, which is mentioned as a hosting provider in the README.md.
Build
The portal is built using the next build command. The output is placed in dist/apps/portal as defined in apps/portal/project.json.
- Build command:
pnpm build:portal(which runsnext build) - Output directory:
dist/apps/portal
Sources: apps/portal/package.json:14, apps/portal/project.json:6-11
Configuration (next.config.js)
The next.config.js file contains important configurations for deployment:
- Output Mode: The
outputproperty can be set tostandaloneorexport, which optimizes the build for different deployment environments (e.g., Docker or static hosting). - Image Optimization: Allows images from
storage.googleapis.comandlh3.googleusercontent.com. - Redirects: Redirects the root path (
/) to/media/images. - Rewrites: Rewrites requests to
/fonts/:path*tohttps://api.rec.so/fonts/:path*, proxying font requests to the API domain. - Sentry: The configuration is wrapped with
withSentryConfigto enable Sentry error monitoring in production.
Sources: apps/portal/next.config.js
Serving
In a production-like environment, the portal can be served using next start. The project.json file defines a serve configuration for production that sets the hostname to app.rec.so.
Sources: apps/portal/project.json:23-27
Browser Extensions (apps/extensions) Deployment
The browser extension is built using Webpack. The build process generates different outputs for development and production, and includes steps for packaging the extension into a ZIP file for distribution to browser stores.
Build and Packaging
The build is managed by Webpack and configured in apps/extensions/webpack.config.js.
- Build command (Production):
pnpm build:extensions - Output directory (Production):
apps/extensions/build/prod - Packaging command:
pnpm zip:prodcreates a zip archive from thebuild/proddirectory.
The Webpack configuration handles:
- Entry Points: Compiles multiple entry points for different parts of the extension, such as
background.js,popup.tsx, and content scripts. - Loaders: Uses
esbuild-loaderfor TypeScript/JavaScript, and various loaders for CSS, SASS, and assets. - Manifest Transformation: The
manifest.jsonis transformed during the build process. It uses a template to inject the package version. - Environment-specific builds:
webpack.dev.jsmerges with the base config to create a development build with source maps in thebuild/devdirectory.
Sources: apps/extensions/package.json:34-38, apps/extensions/webpack.config.js, apps/extensions/webpack.dev.js, apps/extensions/src/manifest.json
This diagram outlines the build and packaging process for the browser extension.
Summary
The deployment strategy for ever-rec is well-structured for a monorepo, using Turborepo for efficient, parallel builds. Each application (api, portal, extensions) has a tailored build and deployment pipeline suited to its technology stack:
- The API is a standard Node.js/NestJS application, built and run as a server process, likely within a container on a platform like DigitalOcean.
- The Portal is a Next.js application, configured for modern web hosting platforms like Vercel, leveraging features like serverless functions and optimized image handling.
- The Browser Extensions are built with Webpack, producing a structured directory that is then zipped for submission to browser web stores.
This separation of concerns allows each part of the platform to be deployed independently using best practices for its specific architecture.