Nest repository that demonstrates the following features:
- Use of nestjs/typeorm with a PostgreSQL backend.
- Use of typeorm migrations to create initial database structure on an empty precreated database.
- Use of nestjsx/crud for generating Rest API endpoints, swagger documentation and request body validation.
- Jest unit tests with examples of mocking.
- Jest e2e tests with supertest.
$ npm install$ npm run buildA PostgreSQL database is used for the backend. This is configured by setting the following environment variables:
| Variables | Description |
|---|---|
| DB_HOST | Database hostname |
| DB_NAME | Name of the database |
| DB_PASSWORD | Database password |
| DB_PORT | Port of database |
| DB_SCHEMA | Schema of the database |
| DB_USER | Username of database owner |
- Create a test.env and development.env file that encapsulates these environment variables for test and development environments respectively. Both test.env and development.env files should exist in the root folder of the source repository. These are not commited into source control, however a sample is provided in source control: config.sample.env. For production environments set the environment variables on the hosting environment.
- Create a new empty PostgreSQL database with name and schema matching the value of the DB_NAME and DB_SCHEMA variables respectively. Ensure that the database and schema is owned by the user referred to in the DB_USER environment variable.
- Migrations will automatically create the schema.
- A dedicated Config module automatically and transparently creates a configuration object dependent upon the build environment. For production environments the config object is derived from environment variables within the inherent shell. For development and test environments the configuration object is derived from the development.env and test.env files respectively. In summary a ConfigService class exposes a TypeOrmModuleOptions instance, representing a configuration object for connecting to the database and performing migration/seed operations. Please refer to the source code for the config module within the src/config folder for further details.
- The database configured via dotenv file, test.env, is dropped each time the Application module is instantiated and migrations are run from src/database/migrations. This is performed transparently to the developer and allows each test to use a fresh database environment. Test data is automatically seeded when the SeedModule is imported. Seeding is only performed for development and test build environments and is initialised during the application bootstrap process.
- An alternative mechanism would be to use transactions to rollback after each test has completed. The typeorm-test-transations library uses this approach, although it uses the @Transactional decorator which is marked as deprecated in future releases of typeorm. Another solution could be to use typeorm EntityManager / QuerryRunner to manage transactions.