/true-pokemon-server

Single-endpoint API to showcase sound software engineering principles, such as CQRS, Mediator pattern, Clean Architecture

Primary LanguageC#The UnlicenseUnlicense

True Pokémon Server

This is a showcase project exposing a single API that, given a pokémon name, will return a description in 'Shakespearean' terms.

NOTE: this project has a level of complexity that I wouldn't necessarily recommend for an API with simple requirements like this one: this is meant to showcase how I would approach building a solution for a reasonably-sized project. The logic is basically contained in the PokemonQueryHandler class.

The project is based on the template I'm building on my other repo.

There is a frontend for this API living on this other repo.

Example

Request:

GET http://localhost:5000/pokemon/pikachu

Response:

{
  "name": "pikachu",
  "translation": "At which hour several of these pokémon gather,  their electricity couldst buildeth and cause lightning storms."
}

NOTE: if, for some reason, it's not possible to get the translation, it will return a default one.

How to run this project

  • Clone the repo
  • Run it:
    • Run with an IDE:
      • Install Visual Studio or Rider.
      • Just open the TruePokemon.sln file and run the TruePokemon.Api.csproj project in development mode, it should start the API listening on the port 5000
    • Run with Docker:
      • Install Docker
      • Via terminal, cd into the solution folder and Build the image via docker build -t true-pokemon -f src/TruePokemon.Api/Dockerfile .
      • Run it with: docker run -p 5000:5000 true-pokemon
  • Test it using the built-in Swagger documentation at http://localhost:5000/swagger/index.html
  • You should clone the frontend repo and use them together

Features

  • Project structure following Clean Architecture principles
  • Based on .NET 6 for Long Term Support
  • Simplified .NET 6 startup hosting model
  • OpenAPI documentation generated automatically via Swagger
  • CQRS with full separation between Read and Write repositories
  • Simple Mediator abstraction for CQRS and no-magic, in-memory implementation relying on the standard IServiceProvider DI container abstraction (~50 lines of code)
  • SimpleInjector open-source DI container integration for advanced service registration scenarios
  • Aspect-oriented programming using Decorators on the above-mentioned mediator
  • Resilient HttpClient instances with exponential backoff + jitter retry policy using Polly
  • Structured logging using the standard MEL interface with the open-source Serilog logging library implementation
  • Testing: separate projects for Unit and Integration tests (libraries used: xUnit, FluentAssertions)
  • Docker support: Dockerfile

TODO

  • More testing
  • Authentication?
  • Automated build and release pipelines
  • Prod release configuration adjustments
  • Browser caching
  • Docker-compose