This project was developed mainly as a source project for a subject (PIT-II) of college. The purpose of this subject was to develop a backend server and frontend application to sell cupcakes and other variants. You can find the frontend application here.
- Project Architecture
- Auth & Security
- Endpoints
- Tests
- Deployment: AWS & Github Actions
- License
- Get in touch
The architecture of this project is very simple to understand. As the scope of it is small and there is no perspective of growing up and expand it's domain, I've decided to implement a simplified version of the Onion Architecture. The project was divided into two main layers: API and CORE.
This layer is responsible for handling and exposing resources to external services through endpoints and also to control the security of these endpoints. It's not responsible for handling business logic or to integrate with external services. It depends on the CORE layer.
This layer is responsible for the business logic and integration with external services and/or other external resources, as database for example. It does not depend on any other layer.
For bigger projects we could and should improve this architecture. There are few ways we could do this, if the project grows in terms of external integrations and have to do many conversions and aggregations of information from these services in order to return a single object response to the user, we could implement a new layer called INFRASTRUCTURE. This way we would break down the responsabilities between them and segregate it better. This new layer would be responsible only for implementing the integration with external resources/services. The CORE layer would have no dependency and would be simply responsible for data manipulation.
Also we could start to think in breaking this down into microservices, since we have a few mixed domains in this project that could be splitted up into new services: Products, Orders, Payment and User.
This project has implemented a few layers of security using spring features and AWS Secrets Manager and also custom encryption with SHA-256.
In order to protect the user input for sensitive information that does not need to be known to perform operations, this project has implemented a custom annotation that encrypt nominated fields at controller level.
To achieve this I've created a custom class level annotation @Encrypted that accepts an array of properties name that should be encrypted. It implements the @Constraint annotation from javax validation, so it's executed when the object annoted with it is validated by spring. It relies on EncryptService class that uses SHA-256 encryption.
It has a great level of security beacuse as the encryption occurs at validation level of spring, the field is encrypted before the first instruction of the controller method that was invoked. This way even if we declare a log instruction into the first line to log the password, the result logged in would be the encrypted password and not the raw value. Also all the folowing flow would have the encrypted value, so the user credentials are fully protected.
To protect credentials and secrets from being exposed the projects uses the spring capacity to access environment variables and map into properties that could be injected as value into class properties together with AWS Secrets Manager.
This way the credentials are managed by AWS services and injected in the container as environment variables where the application will be executed, then when spring try to read these values it will have the secret ready to be used. With this we avoid defining sensitive information as database credentials direct into application.properties. To have more information regarding this flow, please refer to the Deployment: AWS & Github Actions section.
This project has implemented unit testing with Junit 5 and database integration tests using testcontainers. To know more about testing application using Spring + JUnit 5 please read the article I've written regarding this subject and also refer to the base project of the article.
This project uses Github Actions to deploy the application on AWS and also to validate pull requests before merging into master branch.
When a pull request is opened with target master branch it triggers the github actions defined in gradle.yml file. When this file is executed by Github it runs the command ./gradlew test --tests that executes all the defined tests. If all test cases are successful it automaticaly approves the PR.
Github detects when the master branch is updated, when this happens it executes the actions defined in aws.yml file. This files defines a sequence of steps necessary to succesfully deploy the application into a container and be ready to receive requests. The image bellow explain beter how this flow works.
Also, during the deploy to AWS this files also defines instructions to execute flyway migrations. These migrations are responsible to keep the database up to date with the defined sql scripts.
This project is under the license GNU General Public License v3.0.
