mod-circulation currently invokes the circulation rules by making a HTTP request to the rules API, via Okapi.
As mod-circulation provides this API this is unnecessary, and has some drawbacks:
- Increases latency of apply the rules
- Uses resources within mod-circulation, including HTTP connections
- Uses resources within Okapi for proxying the request
- Can lead to mod-circulation starving itself of resources
- Separate applying the circulation rules from the API implementation
- Replace the current invocation of the circulation rules via HTTP request with use of separated implementation
- (Optional) Improve the implementation of the rules API to use chained results instead of callbacks
These changes could be done in a sequence as separate activities / pull requests.
Thinking more about LoanCirculationRulesEngineResource and RequestCirculationRulesEngineResource, we can see that these classes couple the rules checking functionality with the handling of service requests. Consequently, within mod-circulation itself (e.g., LoanPolicyRepository.lookupLoanPolicyId()) when there is a need to apply the rules it has to use CirculationRulesClient to call LoanCirculationRulesEngineResource.apply(), which means that it has to go out of mod-circulation, to Okapi, and back into itself. This is wildly inefficient.
I'd like to suggest that we decouple the API service requests handling from the rules lookup/apply functionality so that classes like LoanPolicyRepository doesn't have to use CirculationRulesClient.
Create a new class that extends AbstractCirculationRulesEngineResource to have the rules lookup/apply functionality, which are in the current LoanCirculationRulesEngineResource.apply() method.
LoanCirculationRulesEngineResource calls this new class's method in its apply() methods, passing appropriate parameters from the routingContext to apply the rules.
Internal code such as LoanPolicyRepository can also call this new class without going out to Okapi.