Inventory Go

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.

Requirements

Please, make sure your environnement is set with:

Commands

Start

Run sh ./start.sh to deploy Docker containers

Test

Run sh ./test.sh to run unit tests

Structure

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.

To go further

Possible future improvements:

routes, through gRPC or HTTP, are included withing the layer service. For the sake of clarity, and to separate transport methods from declarative 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.

damienleroux / inventory-go