Disclaimer: This repository contains 2 applications working together to create inventory reservations in a simulated environnement. My intents was to find the right balance between clean archi principle and KISS principle. How to be relevant in creating Go services without overengineering it?
Warning: This repository is a test and is not production ready.
Please, make sure your environnement is set with:
Run sh ./start.sh
to deploy Docker containers
Run sh ./test.sh
to run unit tests
This repository contains 2 applications:
inventory-db
: a service dedicated to Postgres DB inventory management.inventory-api
: a service dedicated to api definition and HTTP connexion.
Caveat: To keep it simple, business rules, like quantity computation rules, are computed within inventory-db
. If this application grows and needs complexe & performance consuming business rules, these business rules could be moved to a dedicated service.
Possible future improvements:
routes
, throughgRPC
orHTTP
, are included withing the layerservice
. For the sake of clarity, and to separatetransport methods
fromdeclarative apis
, this could be split into separated folders.- Add api routes to list existing registrations or update the available quantity for a dedicated Product. For now [products][./applications/inventory-db/services/postgres/init.sql#L49] are not updatable.
- Solve
inventory-db
caveats - Solve
inventory-api
caveats - docker-compose.yml should not instanciate the DB. A dedicated environnement should be available for database interactions, even locally. For now, to ease testing, the DB creation is provided through docker-compose.yml.
- We could replace gRPC connexions with message queues (using rabbitMQ for example). This could be useful if asynchronous actions are necessary.
- Build the services and deploy only binaries. "
go run
" should be kept for development purpose only.