2018-1-9 Meeting notes

Date

Jan 9, 2018

7am PST / 4pm CET

Meeting Link

Note we're using Zoom now:

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/737202874

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

• Questions on Functional e2e testing?

• feature-based dependencies

Discussion items

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