Application generator

The application generator is responsible for generating new applications (services) with all required configurations pre-configured.

You can run the application generator by executing the following command:

nx generate @microservice-stack/workspace:application-generator

Executing the command will start the interactive shell which will guide you through different options for the application generator. These options can also be added directly to the command by using the following flags:

  • --applicationName=<name> This flag sets the application name

  • --includeQueue This flag will include the RabbitMQ queue configuration in the default code generated for the service.

  • --includeRedis This flag will include the Redis configuration in the default code generated for the service.

  • --includeDatabase This flag will include Postgres database configuration in the default code generated for the service.

  • --no-interactive This flag will skip the interactive shell

  • --dry-run This flag will run the generator without actually generating any files.

Executing the application generator command will produce the following file tree:

apps/
├─ api/
│  ├─ service-name/
│  │  ├─ ...config files
libs/
├─ api/
│  ├─ service-name/
│  │  ├─ constants/
│  │  │  ├─ ...config files
│  │  ├─ data-transfer-objects/
│  │  │  ├─ ...config files
│  │  ├─ service-name/
│  │  │  ├─ ...config files

This folder structure ensures that the whole project is tidy, and boundaries between services are well defined.

Each service gets three libraries by default.

  1. Constants library

    This library contains constants such as service name and environment variables enum. This library can be imported by the service application, its libs and all the other services libs.

  2. Data transfer objects library This library contains all the DTOs and interfaces that are shared between services. These can be imported anywhere.

  3. Service library This library contains the default generated module for the service. It shows how modules should be implemented - as libraries. This pattern enables us to optimise CI as well as builds, as only libraries that were affected by code changes will be linted, tested and rebuilt.

Among service configuration files, deployment-values.yaml file is generated. This file contains deployment values overrides for the specific service. In here you can add secrets to env, enable autoscaling and change resource usage limits.

Last updated