139 lines
5.8 KiB
Markdown
139 lines
5.8 KiB
Markdown
# dotnet-interview-exercise
|
|
|
|
This exercise is designed to test your skills in C# and .NET.
|
|
|
|
## Technologies used in this exercise
|
|
|
|
* .NET 8.0 / C#
|
|
* Minimal ASP.NET Core Web API
|
|
* Entity Framework Core
|
|
* PostgreSQL Database (Docker)
|
|
* HttpClient for downstream REST API calls
|
|
* ???
|
|
|
|
## Prerequisites
|
|
|
|
* Latest [.NET 8 SDK](https://dotnet.microsoft.com/en-us/download/dotnet/8.0)
|
|
* Visual Studio Code
|
|
* Docker Desktop and docker compose plugin
|
|
* **Disable Copilot completions** (that would make it too easy...)
|
|
* Be ready for sharing your screen in Zoom
|
|
* Launch settings have been configured to run and debug the web application
|
|
|
|
## Exercise
|
|
|
|
### Phase 1
|
|
|
|
Note: For all API and schemas, see <https://jsonplaceholder.typicode.com/>.
|
|
|
|
* Implement the missing code in `JsonPlaceholderClient.cs`
|
|
* Setup of the client.
|
|
* Method for fetching one post from the external API at `https://jsonplaceholder.typicode.com/posts/{id}`.
|
|
* In our endpoint handler in `Program.cs`, fetch the post with the ID provided.
|
|
* Store the post received in the database using the `Post` entity, but leave out `UpdatedAt` for now.
|
|
* Use <http://localhost:8080/swagger/index.html> for testing.
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
title Overview
|
|
actor B as Swagger UI
|
|
participant S as Service
|
|
participant E as External Service
|
|
participant D as Database
|
|
B->>S: GetPostById
|
|
S<<->>E: GetPostById
|
|
S->>D: Store Post
|
|
S->>B: Return Post
|
|
```
|
|
|
|
**Success Criteria: Verify that the post has been saved with the database with:**
|
|
|
|
```bash
|
|
$ docker compose exec --env PGPASSWORD=password db psql -h localhost -U user --db mydatabase -c "select * from posts;"
|
|
|
|
id | user_id | title | body | updated_at
|
|
----+---------+----------------------------------------------------------------------------+-----------------------------------------------------+------------------------
|
|
1 | 1 | sunt aut facere repellat provident occaecati excepturi optio reprehenderit | quia et suscipit +| 1970-01-01 00:00:00+00
|
|
| | | suscipit recusandae consequuntur expedita et cum +|
|
|
| | | reprehenderit molestiae ut ut quas totam +|
|
|
| | | nostrum rerum est autem sunt rem eveniet architecto |
|
|
(1 row)
|
|
```
|
|
|
|
### Phase 2
|
|
|
|
* Check whether we already have the post in the database.
|
|
* If we do, return the post from the database, but without the internal `updated_at` timestamp.
|
|
* If we don't, fetch the post from the external API and store it in the database, and return it.
|
|
* **Success Criteria: Check the service logs to see if the post was read from the database, or whether the client made a call to the downstream service.**
|
|
|
|
### Phase 3
|
|
|
|
* Set the `UpdatedAt` property of the `Post` entity to the current date and time when storing it in the database.
|
|
* If the post in the database has been updated less than 1 minute ago, return the one from the database.
|
|
* If the post in the database is older than 1 minute (extra short value for testing), fetch the post from the external API again and update it in the database before returning.
|
|
* **Success Criteria: Check the service logs to see if the post was read from the database, or whether the client made a call to the downstream service.**
|
|
|
|
### Phase 4
|
|
|
|
* Think about how we could improve resiliency in downstream API calls.
|
|
* For setup, merge in the changes from the `phase4` branch.
|
|
* It adds chaos-injecting code in `Program.cs` to simulate random failures in downstream API calls.
|
|
* Execute a couple of requests with increasing ids until an error happens.
|
|
* Implement basic resiliency measures to handle these kinds of failures.
|
|
* **Success Criteria: Check the service logs to see the resiliency measures in action.**
|
|
|
|
### Phase 5
|
|
|
|
* Now increase the chaos outcomes rate of 503 to 95% to simulate a partial outage. What is the outcome on our endpoint?
|
|
* Improve the error response returned by handling the downstream error accordingly.
|
|
* **Success Criteria: Service should return the appropriate error response that warrants retrying the call from the client side.**
|
|
|
|
### Bonus Phase 6 (discussion only)
|
|
|
|
* The current DB schema solution has big drawbacks. What are they?
|
|
* How would you implement schema migrations that avoid these issues?
|
|
* What do you need to consider in the setup for proper schema migrations?
|
|
|
|
### Bonus Phase 7 (discussion only)
|
|
|
|
* Imagine the following deployment scenario:
|
|
* The service is deployed to and running in the Elastic Container Service (ECS) in Amazon AWS
|
|
* The downstream service requires authentication
|
|
* How would you store and retrieve the required credentials?
|
|
* What options do you see to also require authentication on our little service?
|
|
|
|
## Troubleshooting
|
|
|
|
### Start database manually
|
|
|
|
Open a terminal at the repo root and execute
|
|
|
|
```bash
|
|
$ docker compose up -d db
|
|
|
|
[+] Running 3/3
|
|
✔ Network dotnet-interview-exercise_default Created 0.0s
|
|
✔ Volume "dotnet-interview-exercise_db_data" Created 0.0s
|
|
✔ Container dotnet-interview-exercise-db-1 Started 0.1s
|
|
```
|
|
|
|
### Cleanup database
|
|
|
|
In case something went wrong, wipe and rebuild the database
|
|
|
|
```bash
|
|
$ docker compose down -v
|
|
|
|
[+] Running 3/3
|
|
✔ Container dotnet-interview-exercise-db-1 Removed. 0.2s
|
|
✔ Network dotnet-interview-exercise_default Removed. 0.2s
|
|
✔ Volume dotnet-interview-exercise_db_data Removed. 0.0s
|
|
|
|
$ docker compose up -d db
|
|
[+] Running 3/3
|
|
✔ Network dotnet-interview-exercise_default Created 0.0s
|
|
✔ Volume "dotnet-interview-exercise_db_data" Created 0.0s
|
|
✔ Container dotnet-interview-exercise-db-1 Started 0.1s
|
|
```
|