Skip to content
This repository has been archived by the owner on Apr 30, 2021. It is now read-only.

Latest commit

 

History

History
77 lines (44 loc) · 4.59 KB

README.md

File metadata and controls

77 lines (44 loc) · 4.59 KB

Joseki Backend

Getting started

The project uses dotnet core 3.1 and entity framework core code first to manage database access layer.

Current backend version supports only MS SQL database.

Code style

The project uses StyleCop to enforce common styling across the project. StyleCop generates warnings, while dotnet-projects are set to treat warnings as errors, which causes build failure on styling violation.

Some StyleCop rules are diable with GlobalSuppressions.cs file, which is included as link to each project. The suppressions file is the consensus between development team at the moment of writing. In general, it's not suggested to make changes to suppressions file. Any concerns related to the styling rules should be raised to the dev-team via github-issues.

Database

The recommended way to manage database localy is through ef core cli and local MS SQL instance.

Once the ef core cli is installed, the local database instance could be provisioned with dotnet ef database update. The command uses Connection String specified in JosekiDbContext class, which points to localdb by default.

Changing database schema

The Joseki project already has several EF migrations in Joseki Migrations folder.

Each migration is a set of changes, that Entity Framework applies to a database: adding new tables, modifying existing one, insert data or migrate data from one table to another. Existing migrations already has samples for each of these cases.

To add a new migration to the project:

  • update JosekiDbContext object and entities objects according to the needs;
  • run dotnet ef migrations add MIGRATION_NAME;
  • review generated migration files and update them if needed;
  • test created migration on localdb with dotnet ef database update.

NOTE: EF auto-generate c# code, which should be carefully reviewed and adjusted correspondingly. For example, added changeset might drop a column or index, whihc might cause undesired data-loss. Some of existing migration objects already did a similar task.

NOTE2: The project uses StyleCop to enforce common styling. To skip validation of auto-generated files, add // <auto-generated /> instruction at the very top of a file and add #pragma warning disable 1591.

Runnnig the project locally

Joseki has quite flexible configuration, which consist of Database and Blob Storage connection strings, cache properties, and others.

In most cases, during the development process access to real Blob Storage service is not required. The rest of configuration Joseki reads from config file. Use these environment variable to tune local environment:

  • DEV_JOSEKI_BLOB_STORAGE_ENABLED=false to switch off blob-storage related code;
  • DEV_JOSEKI_AUTH_ENABLED=false to enable/disable authentication,
  • JOSEKI_CONFIG_FILE_PATH to specify absolute path to configuration file;
  • ASPNETCORE_ENVIRONMENT=Development to turn-off database migration.

The sample usage of these three parameters could be found at local_development launch-profile.

The sample config file is attached to unit-tests project: config.sample.yaml.

From cli

To build the sources: dotnet build ./joseki.be/

To run unit tests: dotnet test ./joseki.be/

To start: dotnet run --project ./joseki.be/webapp/webapp.csproj --launch-profile local_development

From docker

To run the application:

docker build --target webapp --build-arg var_environment=Development -t joseki-backend:latest .
JOSEKI_CONFIG_FILE_PATH=full_path_to_config_file
docker run -v $JOSEKI_CONFIG_FILE_PATH:/app/config.yaml -e JOSEKI_CONFIG_FILE_PATH=/app/config.yaml -e DEV_JOSEKI_BLOB_STORAGE_ENABLED=false -p 5001:8080 --rm -it joseki-be:latest

Swagger

When service is running, it serves swagger interface at http://localhost:5001/swagger.

The used models documentation could be found at Schemas section:

Swagger schema documentation