Asking for comments on this approach
The idea here is to simplify how we are passing the request the metadata type header "X-Flow-Id" to web service client methods which in turn propagate it to the other microservices that they are calling for flow tracking purposes.
Instead of passing e.g. an extra request-ctx
parameter to the web service client method:
(defn entities [component entity-id request-ctx] ...)
we can include the flow-id
as a stuartsierra/component
dependency
(defn entities [{:keys [flow-id] :as component} entity-id] ...)
This way all the business logic between the API controller method and the web service client does not have to directly know about the request-ctx
or flow-id
, and we do not need to include there extra parameters for just passing the metadata kind X-Flow-Id header to the dependency.
(defn business-logic [{:keys [client-component]} entity-id request-ctx]
...
(client/entities client-component entity-id request-ctx)
...
)
becomes
(defn business-logic [{:keys [client-component]} entity-id]
...
(client/entities client-component entity-id)
...
)
The dependencies is handled when calling component/map->SystemMap
, and the business logic and API controller code stays simpler, and can concentrating to the actual business logic.
The clear downside here is that getting the flow-id header using (flow-id/to-header flow-id)
in the web-service-client/entity
method, does not make very clear that we are dealing with dynamic binding, which can cause problems in multithreaded environments.