System Architecture
Core Features
Data Management
Frontend Components
Extensibility
The following files were used as context for generating this wiki page:
The API architecture is built upon the NestJS framework, providing a structured and modular approach to developing server-side applications. It serves as the central backend for various functionalities, integrating numerous domain-specific modules, handling requests, and providing a robust and scalable foundation.
The core of the API is defined by its entry point (main.ts), which initializes the NestJS application, configures global middleware, security settings, and API documentation. The AppModule acts as the root module, orchestrating the integration of various feature modules, configuration settings, and global guards to manage the application's overall behavior.
The main.ts file is the primary entry point for the API application. It is responsible for bootstrapping the NestJS application, applying global configurations, setting up middleware, and starting the HTTP server. Before the NestJS application starts, environment variables are loaded to ensure proper configuration.
The bootstrap function performs several critical steps:
AppModule.helmet middleware to set various HTTP security headers, including Content Security Policy (CSP).express.json and express.urlencoded to handle request body parsing, with a generous limit of 150MB to accommodate large payloads like base64-encoded attachments.ValidationPipe globally to enforce data validation, whitelisting, and automatic transformation of incoming data.1./api/docs. In development environments, it also writes the OpenAPI specification to a JSON file.3333).SIGTERM and SIGINT signals to ensure the application closes gracefully.Sources: apps/api/src/main.ts:1-93
The AppModule (app.module.ts) serves as the root module of the NestJS application. It aggregates all other feature modules, global configurations, and providers, defining the overall structure and dependencies of the API.
AppModuleimports: This array lists all the modules that AppModule depends on. It includes:
ConfigModule: For loading and managing application configurations.ThrottlerModule: Implements rate limiting to protect against abuse.AuthModule, OrganizationModule, DevicesModule, TasksModule, SOAModule, CloudSecurityModule, etc.).controllers: Declares AppController, which handles basic routes like the root redirect to API documentation.providers: Registers services and other injectable components, including AppService and a global ThrottlerGuard for rate limiting.Sources: apps/api/src/app.module.ts:1-85
The ConfigModule is configured globally within AppModule to load environment-specific configurations. It uses awsConfig and betterAuthConfig to provide structured configuration objects throughout the application. The .env file is loaded manually in main.ts before NestJS initializes, ensuring that environment variables are available for configuration loading.
The ConfigModule is configured with isGlobal: true, making the configuration available across all modules without needing to re-import it. The load property specifies configuration factories (awsConfig, betterAuthConfig) that provide typed configuration objects.
Sources: apps/api/src/app.module.ts:10-21, apps/api/src/main.ts:1
When a request arrives at the API, it passes through a series of middleware, guards, pipes, and controllers before reaching the business logic in services.
Sources: apps/api/src/main.ts:1-93, apps/api/src/app.module.ts:22-30, apps/api/src/app.controller.ts:1-12, apps/api/src/app.service.ts:1-7
The API employs several global mechanisms to ensure security, performance, and data integrity:
origin: true) to allow client applications to interact with the API.express.json and express.urlencoded are used to parse incoming request bodies, with a 150mb limit to support large data transfers.ThrottlerModule that limits requests to 100 per minute per IP address, preventing abuse and ensuring service availability.Sources: apps/api/src/main.ts:18-47, apps/api/src/app.module.ts:22-30
A global ValidationPipe is applied to all incoming requests. This pipe automatically validates incoming data against defined DTOs (Data Transfer Objects), ensuring that requests conform to expected schemas.
The ValidationPipe is configured with:
whitelist: true: Removes properties that are not defined in the DTO.forbidNonWhitelisted: true: Throws an error if non-whitelisted properties are present.transform: true: Automatically transforms incoming payload objects to DTO instances.transformOptions: { enableImplicitConversion: true }: Enables implicit type conversion for primitive types.Sources: apps/api/src/main.ts:50-59
The API supports URI-based versioning, allowing different versions of endpoints to coexist. The default version is 1.
app.enableVersioning({
type: VersioningType.URI,
defaultVersion: '1',
});This means endpoints can be accessed like /v1/resource or /v1/another-resource.
Sources: apps/api/src/main.ts:61-64
The API automatically generates and serves interactive documentation using Swagger (OpenAPI). This documentation is accessible at /api/docs.
1.0).X-API-Key header).packages/docs/openapi.json for external tooling or reference.Sources: apps/api/src/main.ts:68-93
The root path (/) of the API is configured to automatically redirect clients to the Swagger documentation page (/api/docs). This redirect is excluded from the generated Swagger documentation itself.
@Controller({ version: VERSION_NEUTRAL })
export class AppController {
constructor(private readonly appService: AppService) {}
@Get()
@Redirect('/api/docs', 302)
@ApiExcludeEndpoint()
redirectToSwagger():
Sources: apps/api/src/app.controller.ts:1-12