-
Features:
- Crud API of customers
- Search endpoint to execute a free text across all customer fields
-
Technologies
- Kotlin
- Spring
- Boot
- MVC
- Data (Postgres and ElasticSearch)
- Flyway
- Cloud Messaging (SNS/SQS)
- Databases
- Postgres
- ElasticSearch
- LocalStack
-
Main Decisions
- Monolith first approach
- We choose to use a monolith first approach with two main packages, because if our project grow we can easily broke in microservices:
- Package
api- Have the responsibility to manage all customer operations (Create, Read, Update, Delete, List) in a relational database (Postgres) and produce messages every time that have a change in the customer state.
- Package
searcher- Have the responsibility to manage all search operations in a NoSQL database (ElasticSearch), our first search operation is a full text search in all the customers fields
- Package
- We choose to use a monolith first approach with two main packages, because if our project grow we can easily broke in microservices:
- SQS/SNS
- We choose to use SQS/SNS approach to represent an a async architecture with a component responsible for the search and another with the domain, the best approach right here, is to use a event broker such as Kafka and produce events like
CustomerCreated,CustomerUpdatedorCustomerDeletedinstead of produce a command with the customer data.
- We choose to use SQS/SNS approach to represent an a async architecture with a component responsible for the search and another with the domain, the best approach right here, is to use a event broker such as Kafka and produce events like
- LocalStack instead of terraform the infrastructure
- We choose to use LocalStack instead of terraform because we will need to bootstrap all the infrastructure and it will take a lot of time and a lot of code, because, maybe we will need to build some terraform modules like the ecs because the community module isn't production ready (ECS community module)
- Use package by layer
- Even the package by feature being our favorite approach for microservices we decided to move with a package by layer approach to make more easy to understand the components and the responsibilities.
- Functional tests instead of automatized tests :(
- Due our time to finish the project we didn't have any automatized test for the
searchermodule, this module had a lot of tests but exclusively functional tests, during this week we will automatized all this tests :)
- Due our time to finish the project we didn't have any automatized test for the
- Monolith first approach
-
How to run locally
- Prerequisites:
- git
- Java v11
- Docker
- Docker compose
- Copy the
application.yaml.samplein thesrc/main/resourcesLike this:cp src/main/resources/application.yaml.sample src/main/resources/application.yaml
- With the
application.yamlcreated run this make command:make local-without-application
- After the bootstrap of
localstack,postgresandelasticsearchyou can run the application with the./gradlewor run theMain classin some IDE./gradlew bootRun
- Prerequisites:
gadsc/customers
Folders and files
| Name | Name | Last commit date | ||
|---|---|---|---|---|