HVV Case Study for Infrastructure and Lot 2

Lot 2: Backend

Getting started

1. Clone this repository
2. Build the image

   $ docker build -t hvv-case-study -f ./images/base/Dockerfile .

3. Run the image

   $ docker run -p 5000:5000 hvv-case-study

4. Access the API on localhost:5000
5. To get the statistics for a country, use the api/v1/country endpoint with the country name as a query parameter. For example:

   $ curl -X GET http://localhost:5000/api/v1/country?name=germany

6. To get the statistics for a year, use the api/v1/year endpoint with the year as a query parameter. For example:

   $ curl -X GET http://localhost:5000/api/v1/year?value=2020

Infrastructure

• The dev branch is the default branch/trunk for this source code.
• Implementations of two endpoints for gathering statistics have been created.
• A small sample test suite has been created for showcasing a future test-flow.
• Two Github Actions have been created:
  • (Immediate Feedback) On open and sync for any PR targeting dev:
    • runs formatting using ruff, if successful
    • runs a sample test suite of the application.
  • (Deploying) On push to dev(*) a CI/CD pipeline will:
    • runs a sample test suite of the application, if successful
    • builds the application using Docker and push it to a Github Container registry.

Authentication

For self-managed authentication, Keycloak could be used. It allows for user management of out-of-the-box, service-to-service communication, and OAuth-flows. This solution is readily extensible and gives Administrators and Operators control over the whole authentication process.

An alternative is to use a managed authentication provider, through a cloud operator of choice, for instance Amazon Cognito or Azure AD B2C. In this case, managing users/clients can be implemented using OAuth-flows through their preferred authentication provider without the need to manage each provider manually.

Discussion & Future Improvements

• To use a production-level solution for Flask and create TLS certificates for hosting the application.
• Pre-emptive input validation on Endpoints: At the moment we are not prohibiting the input for country names before we have received the input. The reason for this is primarily the lack of requirements for the integration with downstream services (e.g. Lot 1: Frontend), users, or SDKs. Possible options could be:
  • Pre-processing and validating inputs to prohibit malicious attempts before using it.
  • Use the Content-Type application/json to allow users to send data that does not have to be URL encoded (e.g. not having to use %20).
  • Providing users with a list/options of valid inputs (e.g. Dropdown of country names).
• Automatic Documentation Generation: By using modules such as pydoc and Sphinx we would be able to generate canonical documentation for SDK and API reference.

(*) This is equivalent behavior to on merge of PR of branch targeting dev