Or iPhone one-tap : US: +16699006833,,737202874# or +14086380968,,737202874# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923 Meeting ID: 737 202 874 International numbers available: https://zoom.us/zoomconference?m=F0kj5u6u0wFxr7Xfz5NKZxl0xyLhuTPF
Attendees
Nikodem
Lukasz
Klaudia
Mateusz
Goals
review last action items - epics are entered, they need to be groomed and prioritized
Approval notes and quantities fields - separate resource
Notes
Equals and hashcode
equals and hashcode are important!
effects etags - hashcode
basic spring implementation uses the hashcode function to determine/compare on etag
when getting a user's programs, (Set<ProgramDTO>), the id wasn't included and so
EqualsAndHashCode(callsSuper = false) - can be a problem in DTOs
we should likely change all DTOs to callSuper=true on Equals and hash code generation
Next steps: to experiment and report back to tech comm how it went
Fluent builder pattern check-in
Point of using a fluent interface with a builder pattern is to make our tests more readable and maintain
pattern has been adopted widely
concerns mentioned:
Services often use a fluent builder pattern, but the builder object IS the returned object - and doesn't return an instantiated class
UI often returns Javascript classes, rather than plain javascript objects - there isn't clear guideance about which style is preferable
Action Item: audit code-base and find if we're consistent and more importantly which ones are the successful ones
Feature based dependencies
Problem: Microservices however there are hard dependencies between some services - in general we want each service to be independent. (could use some cleanup). Features (from UI/API to database) - we want to use those or re-use those independent of other services / features.
Scope: end state is that ideally most services are fully independent, however not all hard dependencies need to be mitigated.
Services that depend on Reference Data should expect a hard dependency
From others to one another, we'd like to remove hard dependencies.
Example: If we have Requisition service and Stock Management service - non hard dependency is allowing one or the other service to not be launched:
Requisition: the requisition workflow, from grid, to initialization through to final approval all works. (Requisition, Template, status changes - comments, etc)
Stock Mgmt: is creating a stock ledger - stock cards. Daily stock on hand changes.
Goal: is to allow for features to turn on/off based on if a Service is available.
Solutions:
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