On this page

Configuration

This configuration is for the included develop application, which serves as a testbed for testing all libraries. Some of the options below might not apply to your application, adjust accordingly. All commands are expected to be run in the rc-apps/ directory, unless directed otherwise.

Preparation

Before running the application for the first time:

  • copy the .env.sample file as .env
  • run ./cli.js generate:secret and paste the generated key to the created .env file
  • (optional) set APP_NAME and APP_DESCRIPTION for your application
  • (optional) change the APP_PORT, if you have another service listening to port 8000

NEVER re-use a secret. This is used to encrypt the access tokens, and, if leaked, will allow anyone to generate valid tokens and compromise your application.

In addition to the above, we will need to initialize the Vault service, but this will have to wait, as we need to start all the services first

Start Services

Before starting the backend, we need to have a set of complimentary services available:

  • PostgreSQL v12 for storing application data,
  • Redis v5 for caching and event management,
  • MinIO for storing and exchanging data between services,
  • Vault v1.5 for storing secrets (passwords and keys),
  • RabbitMQ v3.8 for exchanging messages between application and external services,

Optionally, we need to start:

Note: The --app develop parameter in each command is optional here, as develop is the default project_

$ ./cli.js services:start --app develop

Data will persist in a apps/develop/data/ directory, created the first time you start development services. Obviously you can provide your own services (adjust .env file to do so). This folder is git-ignored by default.

Database Migrations / Seeds

Now that we have everything up and running, we should prepare the database for the backend:

First we apply the migrations:

$ ./cli.js migration:run --app develop

Then, we seed the database with the appropriate data. To do so, we run:

$ ./cli.js db:seed --app develop

and (using the cursor keys) we select one-by-one the available seeds (asset-types.seed.sql, step-types.seed.sql).

In addition to these seeds, we seed the database with some csv files (we use CSV seeds for performance reasons, as these seeds include a lot of data). We run:

$ ./cli.js db:seed:csv --app develop

and we select one-by-one the available CSVs in order. The order is important here, as there are foreign key constraints that need to be met.

Vault

The first time we need to initialise the Vault service. If we used the default options (as found in apps/develop/scripts/docker-compose.yml) we run:

$ ./cli.js vault:init

If we use an external Vault service, we can provide --host, --port, --shares and --threshold options (run ./cli.js help vault:init for more information).

The script will return a set of keys and a root_token to be added in the .env file. Vault is now initialised, unsealed and prepared to be used by our application.

From now on, whenever we start/re-start the Vault, we only need to Unseal it before we use it, using one of the keys generated the first time (you can find them in .env):

$ ./cli.js vault:unseal -k <ENTER_GENERATED_KEY>

Start Application

Now that everything is up and running, we can start the backend. This can be done using one of the commands below (depends on what you plan to do):

yarn start:dev      # Run in development mode (watch for changes)
yarn start:prod     # Serve the backend (should manually run `yarn build` first)
yarn start          # Run in production mode