FFC – Fast & Furious Cinema

Backend service for mobile/web application for a small cinema playing only movies
from Fast & Furious franchise.
Some assumptions were made and some shortcuts were implemented. So be warned that
this is just an experimental version.

Build and run

There are some prerequisite to play with the project:

• Docker should be installed – as integration
  tests are using Testcontainers to avoid all those
  in-memory/embedded/mocked solutions, and check if integrations really works.
• Docker Compose should be installed – as
  project is using MongoDB for persistence, and starting provided docker-copose.yaml
  is painless way to run it locally.
• OMDb API Key is required – as movie details
  are fetched from OMDb API.

You can build the service and run all the tests with ./gradlew clean build. All boilerplate
REST API code is generated from OpenAPI specification and all
code for mappers is generated from MapStruct annotated interfaces,
so if you decide to import this project to IDE of your choice, some missing classes can be
reported. Just re-build the project to fix that issues.

If you want to start the application locally, then all you have to do is start
all dependencies with:

docker-compose up --detach

And after that start the service with:

ADAPTERS_OMDB_API_KEY=<change-me> ./gradlew bootRun

NOTE: Just remember to use proper API key for OMDb API instead of <change-me>.
And when you are done playing with the application tear down MongoDB
with docker-compose down --volumes.

After application is up and running you can explore the API and play with it using:

• Swagger UI available at http://localhost:8080/swagger-ui/
• GraphQL Playground available at http://localhost:8080/graphql-playground/

Some API methods requires you to be authenticated user. You can use one from table
below. Mind that STAFF role will allow you to execute methods from internal API.

So simple yet so complicated

I have assumed that cinema that is showing only nine rather mediocre movies will not
be operating on daily basis – fixed ticket prices and showing hours. Rather in from
event to event manner. And because of that internal API for showing dates and ticket
prices looks so simple. Staff member can create an event for a given date with list
of screenings and dedicated ticket prices for each of them. Also, that simple PUT for
date method could be easily extended to accept POST-ing an ultimate representation of
everything – Excel spreadsheet (or at least his simpleton brother CSV file).

One of expected results of the challenge was API documentation in OpenAPI/Swagger format.
I have turned that requirement around – I have started with designing
specification and using it as an
an input for generating REST controllers interfaces and models, and input for validator
of incoming requests.

I was trying to design REST API with Richardson’s Maturity Model Level 2 in mind,
and because of that there are separate resources for showings, movie details and ratings.
I hear whining of front-end developers – and now we have to make multiple api calls to
get everything what we need. For example to get movie details and its showing hours
for given day. Well… you don’t have to. As an extra, GraphQL API was implemented,
so you can use it to get what you need. Following query result will return movie title,
average rating and showing times in a single server call.

{
  movieDetails(id: "tt0232500") {
    title
    averageRating {
      averageRating
      votesCount
    }
    showings(from: "2021-12-06", to: "2021-12-12") {
      date
      showings {
        startAt
      }
    }
  }
}

It compiles – deploy

Hell no – there’s still a lot to be done. I think that in Fowler’s Make It Work – Make
It Right – Make It Fast, current state of the service is just after It Work.

At least following should be done:

• Unit tests for all generated mappers, alongside with some programming suggar in form
  of convenient test data builders/fixtures.
• More fine-grained integration tests – now different scenarios are cramped in one place.
  Also some “glue” in form of helper methods should be implemented – for example for
  setting up service state for given scenario.
• Paging in results of API methods returning collections – to avoid returning large payloads
  and crippling service performance.
• Real security config.
• Real cache implementation and configuration – as one currently used can lead to memory
  leaks (no restictions on cache size or time), and return inacurate data as OMDb API
  responses are cached indefinitely.
• Circuit breaker and fallback movie details provider for case when OMDb API would be
  unavailable.
• API rate limiting and monitoring – to know if service is performant enough and to know
  when some less naive (non blocking?) implmentation will be required. Not to forget
  about DoS attacks detection.
• Better exception handling.
• Logging – for now code base is so simple, that I have forgotten about this aspect until now.

GitHub

View Github