Beezy.BackendTest

Eric Bosch Mompió - April 2020

Api call samples

Read this in Spanish.

Online api location

You can find the api located on the following address: https://bit.ly/beezybackendapi

Full url: https://beezybackendtestapi20200425164353.azurewebsites.net/

Swagger access: https://bit.ly/beezybackendtest

Implementation

A REST Api has been developed using .Net Core 3.1

• Part 1: The controller structure is implemented for all described endpoints. Currently returns a 404 error with the following text: "Under construction, come back soon!".

• Part 2: api/managers/billboards/intelligent endpoint implemented with full funcionality for both Database and external Api searches.

  • It has been taken as a consideration that instead of using a flag, the city to be consulted is indicated on the request.
    • If it's empty, it will search on the external Api.
    • If it has value, it will search based on that city.
      • If "All" is used as city, it will return the films with global results.

• Solution implemented using SOLID, YAGNI, KISS and DRY principles.

• Commits serve as history to see the development of the solution.

• For external Api and database acces the Repository pattern has been used to not depend on the data infrastucture directly.

• Healthcheck available on /health

• Pipeline validation via FluentValidation.

• Mediator pattern implemented via MediatR, in this way the controller is decoupled from its dependencies, making its injection and extension easier. MediatR working flow are based on:

  • The request are sent to the handler.
  • It processes the request and generates a response.
  • There may be a broker who acts as validator of the request.

• For logging, it uses Serilog, which allows to configure several outputs (in this case console and file have been used, but could have been extended to cloud solutions such as Graylog). In addition, a pipeline has been configured to write all the MediatR actions.

• MayBe pattern used using Optional, in this way limit cases can be controlled easily.

• For tests, an integration test has been created to check workflow integrity, as well as unit tests for domains and acceptance tests for controllers.

• Hellang.Middleware.ProblemDetails is used for error handling.

• ServiceStack is used for external Api connections.

• Swagger is used for the documentary management of the Api, as well as to provide an environment where to test it.

• Scrutor is used to scan all possible validators created.

• Autofixture is used to declare test cases.

• Bogus is used to generate random test data.

• FluentAssertions is used to help on the creation of test cases.

• NSubstitute is used to mocking the needed processes and services.

Design

Solution implemented following Clean arquitecture by layers, having:

• Infrastucture layer:
  • Proxy for external Api calls.
  • Repository for database queries.
  • Api features (Cross-cutting).
• Domain layer:
  • Entities.
  • Bussiness models.
• Aplication layer:
  • Controllers.
  • Services.
  • Api configuration.

This architecture allows the domain to be agnostic of the rest of the layers, having the infrastructure in the external layer.

Api versioning using specific namespace, that makes a new development or extends a functionality more simple.

Both context and entities obtained using dotnet-ef scaffolding utility, taking specific modifications to adapt the correct use.

Conclusions

• It would have been interesting to create ValueObjects for entities. Using it you can generate various additional validations on creation.

• Polly could have been used to control access on database and change entity framwework to Dapper in order to optimize the queries.

• Use two database contexts: one for reading and one for writing. In this way, data access and its (possible) manipulation can be better controlled.

• Sensitive data are exposed on configuration (appsettings). In that particular case there are no major security problems, but in a production environment we could have used a key store manager such as Vault or one offered by Visual Studio, although this one does not get along very well with Docker or similars.

• Api deployed on Azure

• Github action created to automate compilation.