Configuration Handling

Overview 

@Attila please review it

Aim of the configuration handling is keeping all environment dependent variables in the database. The schema of the configuration is identical so the code is just using the variable values without knowing the exact environment. So the code is completely independent of the environment.

The database is the only one dependency but this is an "dynamical" dependency. We are accessing firestore without any URL or static parameters. It s connected to the account where the application is running. 

We implemented a database initialization so we can start the application always from scratch. 

1. 1. We are implementing a setup process. If the database doesn’t contain the configurations root collection we import it from a initial configuration JSON file which stored in the repository. This initialization is the first service which is called at the beginning after deployment automatically by the CICD pipeline or from the emulator start script of the environment is started locally. This ensures that the application can be started with an empty database. 

   2. We are providing different initial configuration for the different environments (production, test, emulator, …) and the CICD pipeline decide which one will be used. So the code must be environment independently and doesn’t know on which environment it is running.

Hierarchy

Root collection: configurations

Domain configuration:

We are preparing a multi domain structure (REGISTRATION, INVOICING, DEFAULT ...) but we are using only the DEFAULT document first.

Domain Default

alertInfoUrl: GChat web hook

alertWarningUrl: 

alertErrorUrl:

alertFatalUrl:

frontendBaseUrl:

backendBaseUrl:

owners: [default]

Owner Configuration 

Optional each property defined on the domain level. 

name: BESK Kft, ENDRÉDI, Balázs …

address…

entity: INDIVIDUAL_PERSON, LEGAL_ENTITY

country:

properties: []

Property Configuration

Default Handling

We are going to avoid redundant configuration entries. So we are implementing an hierarchical property search. Example: alertInfoUrl

• 1. First we are looking for a configuration value in the given property (attila75studio). 

1. parent: Owner (Balázs ENDRÉDI)

2. Parent: Domain (DEFAULT)

API

The configuration module provides the following functions:

• 1. getConfigForProperty(propertyId, key, defaultValue)

  2. getConfigForOwner(ownerId, key, defaultValue)

  3. getDefaultConfig(key, defaultValue)

Default value (optional)

Initialization

An init cloud function is implemented. As Parameter the name of the initial configuration will be passed (config-prod, config-dev, config-emulator, config-build-server)

This checks if the configurations root exists. 

If not it will be created based on the file. 

This service will be called by the CICD pipeline if the deployment was successfully. 

On the local environment it will be called by the emulate command and executed each time because the emulator is started with an empty firestore instance. 

If the initialisation ended a GChat message will be sent. 

Info: successful 

Error: some error found but the system is stable

Fatal: initialisation failed

Frontend

Guest Pages

Guest pages are simple pages without any Firestore connection. Dynamical parameters are passed as parameter or body. 

Static variables like backecdBaseUrl is generated into the html page as environment variable.

Admin Pages

Fronted is connected to the Firestore configurations collection. 

If the frontend has been started the configuration musst be initialised by the backend. 

Config search provides the same logic as described above. Probably a single codebase can be implemented used on both side.