moviedb-proxy

“Architecture”

A regular Express application handles the routing.

The application is injected with a TmdbService, an interface for any code to communicate with TMDB. TmdbService doesn’t know about Express.

TmdbService itself uses an HTTP client to talk to the actual service, so that we can test each boundary. In the live application, Axios is used.

Prerequisite: get a TMDB token

Register at https://www.themoviedb.org/ and request an API token. Store it safely and properly pass it to the docker container at runtime.

Run in docker

First, build the image:

docker build -t moviedb-proxy .

Then, start a container in the foreground with:

docker run --rm -p 8080:8080 -it --init -e TMDB_API_KEY=xxxxx moviedb-proxy:latest

or start a detached container with:

docker run -d -p 8080:8080 -e TMDB_API_KEY=xxxxx moviedb-proxy:latest

If you pass -e DEBUG=0, you opt-out of getting a log of each exception at stderr.

Debugging the built docker image

docker run --rm -p 8080:8080 -it --init -e TMDB_API_KEY=xxxxx moviedb-proxy:latest sh

You could also debug a specific target in the multi stage build.

AC

  • [X] get the correct data
  • [X] tests (mock external service)
  • [X] tests (our service)
  • [X] run service in docker
  • [X] run tests in docker

my personal shoulds

  • [X] typescript
  • [X] multi-stage docker builds (shared base between “run” and “test”)

Out of scope:

  • caching responses
  • verifying that the data from TMDB matches the defined TS interfaces
  • not removing duplicates from the combined popular/top-rated lists
    • if they are the exact same lists, we would issue too many requests to find differences