email_newsletter_api/docs/technical_write_up.md
minhtrannhat 84fc74a0d1
feat: subscribe API route skeleton
- Added `serde` crate for serialisation or deserialisation of data
- Added test cases for the `subscribe` API route
- Refactor the testing setup to another module `test_utils`
- use random TCP port for testing
2024-04-22 17:00:55 -04:00

25 lines
1.3 KiB
Markdown

# Technical Write Up
## Routes
- `health_check`: returns a HTTP code 200 if the server is up and running. Response body is empty.
- `subscribe` returns a HTTP code 200 if the user successfully subscribed to our email newsletter service. 400 if data is missing or invalid.
## The `tokio` Async Runtime
`tokio` will be the engine in charge of driving Futures to completion
- `#[tokio::main]` macro is just a builder to help building the runtime. It is basically saying, we want this async function to be run.
- `tokio::spawn(/*async task*/)` will spawn an async task to be run. We can continue executing other code concurrently while `task` runs in the background. If we need to wait for `task` to complete before proceeding, we can use `task.await` (which `#[tokio::test]` will take care for us in the mean time).
### Testing with `tokio`
- Each test has to be marked `#[tokio::test]`.
- This macro will build a new async runtime for that one test.
- By calling `spawn_app()`, we will get a API HttpServer running for the entire duration of the single test that the macro above belongs to.
## The Test Suite
- The OS will find an available port for the test suite to use.
- We use the same PostgreSQL database instance for both testing and production environment (might bite us in the ass later ?).