The project follows a clean architecture, with the application layer interacting with the external system through a data provider interface. This allows the application layer to be isolated from the implementation details of the external system and makes it easier to test and maintain the code.
- Java 17: The backend system is implemented using Java 17, the latest stable available versions of this language, which provides us with different features that we take advantage of in the API implementation.
- Spring boot: The system uses Spring Boot as the web framework to handle HTTP requests and responses.
- Docker: Docker is used to containerize the application and its dependencies.
- Auth0: Auth0 is used as provider to manage the authentication and authorization of the application.
- OpenAPI 3: OpenAPI is used to generate the API documentation.
- Open a terminal and go to the project folder.
- Start the application:
mvn spring-boot:run
- Install docker on your computer, if you do not already have it.
- Open a terminal and go to the project folder.
- Build the image:
docker build -t java-monkey-api . - Start the application:
docker run -p 8080:8080 java-monkey-api
- Install docker and docker-compose on your computer, if you do not already have it.
- Start the application:
docker-compose up
Go to http://localhost:8080/actuator/health to see that everything is up & running!
ℹ️ To simplify the initial use of the API, a user with administrator permissions has been provided:
- Username:
test@email.com - Password:
Password!
GET /actuator/health- Health checkPOST /login- LoginGET /swagger-ui.html- Swagger UIGET /v3/api-docs- OpenAPI specification
GET /users- List all usersPOST /users- Create new userDELETE /users/{id}- Remove a userPATCH /users/{id}- Update a userGET /users/{id}/admin- Change admin status
GET /image/upload- Upload an imageGET /customers- List all customersPOST /customers- Create customerGET /customers/{id}- Get customer by idDELETE /customers/{id}- Delete customerPATCH /customers/{id}- Update customer
Once the app is running, you can access to the swagger UI by going to the following URL: http://localhost:8080/swagger-ui.html, additionally you can get the OpenAPI specification in the following URL: http://localhost:8080/v3/api-docs or download it in yaml format: http://localhost:8080/v3/api-docs.yaml
Attached with the project is a Postman collection with all the API calls to easily test the application.
- Spring Boot Actuator: Used to expose the health check endpoint.
- Lombok: Used to reduce boilerplate code in the project.
- PostgresSQL: The driver to connect with the database used in the project.
- H2: in-memory database used for testing.
- Flyway: Used to initialize the tables and manage database migrations.
- OpenAPI: Used to generate the API documentation.
- Spring Doc OpenAPI: Used to generate the API documentation.
- Clean Architecture: In the project we have always maintained a clean architecture, giving great importance to not coupling the domain and application layers to any framework. Pushing these needs to the infrastructure layer.
- SOLID: We have always tried to follow the SOLID principles, which are the basis of good software development.
- The application has been organized into 3 main packages. Two domain bundles have been created,
customerandadminto separate all its domain classes and behavior. In parallel. we have created asharedpackage where the classes that will be used by all the domains are added. - In the infrastructure structure layer we have the configuration package where we can find:
- The DatabaseConfig: which is responsible for configuring the database connection.
- The DependencyInjectionConfig: which is responsible for configuring the dependency injection of the domain bundle.
- application.yml
server.shutdown = graceful: This property is responsible for allowing the application to finish the current requests before shutting down.
- DB Migration folder: This folder contains the scripts that are executed when the application starts. Are responsible for creating the tables in the database if they do not exist and migrating the database if necessary.
- Exception are defined individually in the exception package and are managed by the ControllerAdvisor to keep a simple but ordered and powerful error handling.
- Testing: The project has a current testing coverage of 90% of the lines of code. Could be increased, finishing the configuration of the classes that should be excluded from the test.
- Unit Tests: All the unit tests classes are tagged with the
@Tag("unit-test")annotation to be able to execute them separately from the integration tests. - Integration Tests: All the integration tests classes are tagged with the
@Tag("integration-test")annotation to be able to execute them separately from the unit tests.
- Unit Tests: All the unit tests classes are tagged with the