chore: add make targets
This commit is contained in:
37
README.md
37
README.md
@@ -4,15 +4,15 @@ REST API for the TrueLayer Software Engineering Challenge. It returns basic Pok
|
||||
|
||||
## Requirements
|
||||
|
||||
You can run it either with Docker or with a local Rust toolchain.
|
||||
You can run it either with Docker or with a local Rust toolchain. Common commands are available through `make`; run `make help` for the full list.
|
||||
|
||||
### Option A: Docker
|
||||
|
||||
Install Docker Desktop or an equivalent Docker runtime, then run:
|
||||
|
||||
```bash
|
||||
docker build -t pokedex-api .
|
||||
docker run --rm -p 5000:5000 pokedex-api
|
||||
make docker-build
|
||||
make docker-run
|
||||
```
|
||||
|
||||
### Option B: local Rust
|
||||
@@ -28,7 +28,7 @@ rustup default stable
|
||||
Then run the service:
|
||||
|
||||
```bash
|
||||
cargo run --bin pokedex-api
|
||||
make run
|
||||
```
|
||||
|
||||
The API listens on `0.0.0.0:5000` by default.
|
||||
@@ -38,19 +38,19 @@ The API listens on `0.0.0.0:5000` by default.
|
||||
With the API running in another terminal, call it through the small helper binary:
|
||||
|
||||
```bash
|
||||
cargo run --bin pokedex-cli -- health
|
||||
cargo run --bin pokedex-cli -- pokemon mewtwo
|
||||
cargo run --bin pokedex-cli -- translated mewtwo
|
||||
cargo run --bin pokedex-cli -- --base-url http://localhost:5000 pokemon pikachu
|
||||
make cli-health
|
||||
make cli-pokemon
|
||||
make cli-translated
|
||||
make cli-pokemon POKEMON=pikachu BASE_URL=http://localhost:5000
|
||||
```
|
||||
|
||||
## Endpoints
|
||||
|
||||
```bash
|
||||
curl http://localhost:5000/health
|
||||
curl http://localhost:5000/pokemon/mewtwo
|
||||
curl http://localhost:5000/pokemon/translated/mewtwo
|
||||
curl http://localhost:5000/metrics
|
||||
make health
|
||||
make pokemon
|
||||
make translated
|
||||
make metrics
|
||||
```
|
||||
|
||||
Example response:
|
||||
@@ -109,9 +109,7 @@ The service includes:
|
||||
## Development checks
|
||||
|
||||
```bash
|
||||
cargo fmt --all --check
|
||||
cargo clippy --locked --all-targets -- -D warnings
|
||||
cargo test --locked
|
||||
make check
|
||||
```
|
||||
|
||||
The crate denies unsafe code and enables strict Clippy groups: `all`, `pedantic`, `nursery` and `cargo`, with only dependency-version noise allowed.
|
||||
@@ -121,20 +119,17 @@ The crate denies unsafe code and enables strict Clippy groups: `all`, `pedantic`
|
||||
Normal tests mock third-party APIs. A scheduled GitHub Actions workflow runs ignored contract tests nightly against the real PokéAPI and FunTranslations APIs to catch provider contract drift early:
|
||||
|
||||
```bash
|
||||
cargo test --locked --test external_contract -- --ignored --test-threads=1
|
||||
make contract-test
|
||||
```
|
||||
|
||||
## Docker multi-arch build
|
||||
|
||||
```bash
|
||||
docker buildx build \
|
||||
--platform linux/amd64,linux/arm64 \
|
||||
--build-arg GIT_SHA="$(git rev-parse HEAD)" \
|
||||
-t pokedex-api:local .
|
||||
make docker-buildx
|
||||
```
|
||||
|
||||
The Dockerfile uses `cargo-chef` and BuildKit cache mounts for dependency and target directory caching.
|
||||
|
||||
## Production notes
|
||||
|
||||
For a production API I would add per-client or per-token rate limiting instead of one global bucket, retries with bounded exponential backoff, circuit breakers for upstream failures, response caching for PokéAPI data, stronger health checks that distinguish readiness from liveness, dashboards and alerts from the OTEL metrics, and a dedicated OTEL collector pipeline. I would also keep `/metrics` private, add dependency/container scanning, define SLOs, and add contract tests against recorded upstream fixtures.
|
||||
For a production API I would add per-client or per-token rate limiting instead of one global bucket, retries with bounded exponential backoff, circuit breakers for upstream failures, and a bounded LRU/TTL cache for PokéAPI data. Species content changes rarely, so caching successful responses would avoid unnecessary random upstream hits, reduce latency, and make transient provider failures less visible to users. I would also add stronger health checks that distinguish readiness from liveness, dashboards and alerts from the OTEL metrics, and a dedicated OTEL collector pipeline. I would keep `/metrics` private, add dependency/container scanning, define SLOs, and add contract tests against recorded upstream fixtures.
|
||||
|
||||
Reference in New Issue
Block a user