...
- Message-oriented solution
- no services actually know about one another
- I as a service publish messages out into the ether, and those that are interested are subscribed to those messages and act based on them
- Common pitfall is that message format tends to lead to hard dependencies
- Feature-based / flags (lack of a better word)
- re-uses / leverages RESTful HTTP approach (favored API re-use)
- we want to make features turn on / off, and we do that by detecting the deployments intent - a Service is available if it was in the deployment descriptor (docker-compose)
- we need to spike on how to:
- read the docker-compose (docker-compose config --services) and create a feature flag based off services deployed
- we need to publish (consul KV) those flag statuses and consume those in our services (constantly checking? No, config doesn't change. We want on startup - onetime)
- Requisition to Stock Mgmt is a good first step to implement (would spur the discussion about which "features" turn off)
- all stock mgmt fields including reasons for losses and adjustments
Action Items
- Chongsun Ahn (Unlicensed) to try equals and hashcode experiment and report back to next tech comm how it went
- Nick Reid (Deactivated) audit code-base and find if we're consistent and more importantly which ones are the successful ones
- Josh Zamor to write-up feature based dependency spike
- Brandon Bowersox-Johnson to prod the leader to discuss how to untangle Req to SM with feature based flags
...