PTV Street Ressource Task

This task was given as a Take-Home Assignment. The task description is the following:

1. Create a service in dotnet. It has a REST API that serves a resource 'street'. A street can be created and deleted. It has a name, a geometry and a capacity (= how many vehicles can use it within a minute).
2. The street data is stored in a Postgres database, and we use EF core to save data there.
3. Implement an endpoint to add a given single point to the geometry of an existing street on either the beginning or the end, whatever fits better.
   • Bonus: Note that this endpoint has a strange behavior from a user perspective when there are race conditions. Please take care of that in the implementation.
4. Add a hidden feature flag to decide whether the operation (in bullet point 3.) is done on the database level, using PostGis, or withing the backend code, algorithmically.
5. Add a Docker file and a Kubernetes manifest, so we can deploy it as a service with 3 replicas.
6. Also create a docker compose file, so we can locally check everything.

Authentication and API documentation is not part of this task.

API

The following functions are supported:

• POST /api/streets/: Create new Street

  Creates a new street when given the following format:

  {
    "name": String,
    "capacity": int,
    "geometry": [
      {
        "x": int,
        "y": int
      }
    ]
  }
  

  Note that geometry must contain at least two points.

• DELETE /api/streets/<streetname>: Delete a street

  Deletes the street with the given name.

• GET /api/streets/<streetname>: Outputs a street

  Returns the street with the given name in the following format:

  {
    "name": String,
    "capacity": int,
    "geometry": [
      {
        "x": int,
        "y": int
      }
    ]
  }
  

• PATCH /api/streets/<streetname>: Add a given point to a street

  Adds a point to the end of the given street. Optionally, one can specify the method used for this operation. This can be one of either "Backend", "Database" or with "PostGIS". If a different value is specified, an Error is returned.

  {
    "point": {
      "x": int,
      "y": int
    },
    "usePostGIS": bool // Optional, default is 'false'
  }
  

Notes about the Design

The application is written in a clean architecture style, seperating between Infrastructure (PostGIS-Db in this case), Domain, Application and the API layer.

The task was tackled in a test driven development, enforcing the API-behaviour with tests in the /tests folder. These tests use a test-database coming from a PostGIS testcontainer with the testcontainer package.

You can run these tests yourself with dotnet test.

Trying it out yourself

This repo contains a Dockerfile to build the service as a container yourself. You can then supply a connection string to a PostGIS database via the CONNECTION_STRING environment variable. The containers serve their API on the port 8080, bind it however you see fit.

Additionally, a functional Docker Compose setup also exists that spins up three such containers together with a function database. These then serve requests on ports 5001,5002 and 5003.

Note that the database must somehow be initialized with the correct table. The docker compose file contains a migration container that will do just that.

Additionally, feel free to spin these up as kubernetes services. You still need to upload these images to a Hub and fill in the image-field in the k8s manifest though.