- Abstract
- Technologies Used
- Approach to the Solution
- Pending Topics
- Possible Improvements
- How to Run the Application
- How to Test the Application
This project is a solution to the OneBox Software Engineer technical test.
It involves simulating the functionality of an e-commerce system.
To achieve this we implement a RESTful API using clean architecture principles to manage Product and Cart entities.
The API supports CRUD operations for both entities while adhering to industry standards and best practices, such as
API-first development, validation, robust error handling and testing.
- Programming Language: Java 21 🍵
- Framework: Spring Boot 3.4.0 (Spring Web, Spring Data JPA, Hibernate) 🍃
- Database: H2 (In-memory database) 🔋
- Build Tool: Maven 🪶
- API Specification: OpenAPI (openapi-generator-maven-plugin)
- Validation: Hibernate Validator (Jakarta Validation API)
- Testing: JUnit 5, MockMvc 🪲
- Postman: A workspace is created (for demo and manual testing)
- GitHub Workflows: Added an Action to validate Pull Requests
- Docker: optional for an easier deployment 🐋
-
API-First Design:
- Defined endpoints and data models using OpenAPI specifications.
- Autogenerated DTOs and interfaces using
openapi-generator-maven-plugin.
-
Hexagonal Architecture:
- Divided the project into
application,domain, andinfrastructurelayers for better maintainability and separation of concerns. - Used ports and adapters to decouple business logic from infrastructure.
- Applied Vertical Slice to minimize coupling between Products and Carts.
- Divided the project into
-
Entity Relationships:
- Implemented a
Productentity, representing individual items in the catalog. - Designed a
Cartentity with aManyToManyrelationship withProduct, allowing multiple products to belong to multiple carts.
- Implemented a
-
Validation and Error Handling:
- Applied constraints at the OpenAPI Specification level for data validation.
- Used a
GlobalExceptionHandlerfor consistent error responses.
-
Testing:
- Developed integration tests for the endpoints using MockMvc.
- Verified data persistence with H2 and tested invalid scenarios.
-
Incremental Development:
- Followed an iterative approach by first implementing
Api, thenProductfunctionality and last extending it toCart.
- Followed an iterative approach by first implementing
-
Improve Test Coverage:
- Expand unit tests to cover edge cases more comprehensively.
- Improve integration tests bad path coverage.
- Add unit tests to mappers.
-
Security:
- Authentication and authorization mechanisms (e.g., JWT) are not implemented.
- To achieve this,
e-commerce.yamlshould be updated including a SecuritySchema.
-
Code Refactor:
- Extract mappers into a new class.
-
Caching:
- Introduce in-memory caching (e.g., Caffeine) for frequently accessed data like product details.
-
API Documentation UI:
- UI integration for interactive API documentation (e.g.: Swagger UI, Stoplight, Redocly).
-
OpenAPI Refactor:
- Refactor
e-commerce.yamlextracting and reusing schemas, responses, requests and errors.
- Refactor
-
Testing Enhancements:
- Include contract tests to validate API compatibility with consumers.
- Include a Quality Assurance folder to test in depth the use cases.
-
Monitoring:
- Integrate tools like Prometheus and Grafana for performance monitoring and trace logs.
-
API Versioning:
- Introduce versioning to maintain backward compatibility.
-
API Decouple:
- Extract OpenApi generation and data into a spec repository.
-
Data Persistence:
- Transition from H2 to a production-grade database (e.g.: PostgreSQL or MySQL).
-
CI/CD:
- Add environments and GitHub Actions to improve the CI/CD
- Requirements:
- Clone the Repository:
git clone https://github.com/FrancescFe/oneboxchallenge.git cd oneboxchallenge - Build the Project and Run the Application:
docker compose up -d - Access the API:
- The Application runs at
http://localhost:8080 - Postman workspace created for testing/demo purpose
- The Application runs at
- This Postman workspace can be used:
https://www.postman.com/material-operator-40700101/workspace/onebox-challenge
Although in the Integration Tests data is inserted into the in-memory database using a schema.sql and data.sql, outside the context of the tests, no data insertion has been automated. It must be done manually.
