(ChatGPT to the rescue of condensing an internal chat, with some modifications and corrections)
Summary
The current setup for "private endpoints" introduces messaging overhead even when calls remain within the same service. This implementation conflicts with the intent of private endpoints, which is to create reusable client-like abstractions (e.g. a CustomerRestClient-alike alternative for Mats services). Requiring actual request-reply messages for these internal calls add quite a bit of overhead, and thus discourage such abstractions, which can in several instances go against DRY.
Problem Statement
The messaging overhead for private endpoints leads to code duplication due to inefficient invocation of private endpoints. The system currently forces a message request/reply model even when the private endpoint is within the same service.
Proposed Solution
Introduce a requestDirect() analogous to nextDirect():
Checks if the requested endpoint exists within the same MatsFactory instance, allowing a direct invocation without message passing.
Bypasses messaging queues by directly invoking the endpoint, with stack adjustments as needed to simulate the invocation sequence.
Preserves existing reply mechanics without requiring API changes, as the system can infer whether a reply should occur through messaging or as a direct call. This means that implicit replies, such as those returned from lastStage(), would function seamlessly in direct-invocation contexts.
Additionally, consider extending this concept to goto() with a gotoDirect() option for situations where the steps stay within the same service (which often is the case), further optimizing performance and reducing messaging overhead.
(ChatGPT to the rescue of condensing an internal chat, with some modifications and corrections)
Summary The current setup for "private endpoints" introduces messaging overhead even when calls remain within the same service. This implementation conflicts with the intent of private endpoints, which is to create reusable client-like abstractions (e.g. a CustomerRestClient-alike alternative for Mats services). Requiring actual request-reply messages for these internal calls add quite a bit of overhead, and thus discourage such abstractions, which can in several instances go against DRY.
Problem Statement The messaging overhead for private endpoints leads to code duplication due to inefficient invocation of private endpoints. The system currently forces a message request/reply model even when the private endpoint is within the same service.
Proposed Solution Introduce a
requestDirect()analogous tonextDirect():lastStage(), would function seamlessly in direct-invocation contexts.Additionally, consider extending this concept to
goto()with agotoDirect()option for situations where the steps stay within the same service (which often is the case), further optimizing performance and reducing messaging overhead.