To prevent business-logic functions from being bloated with supporting-logic* of shared concerns (e.g. authentication, authorization, logging, profiling, ingress rate-limiting) many backend frameworks allow you put the supporting logic into middlewares/interceptors.
The middleware factors out the supporting logic but at the cost of coupling the logic to the http transport. If the app has other I/O such as CLI commands, or gRPC, then additional work is required to apply the supporting logic to those mediums. So i.e, n number of I/O mediums will require n implementations of middleware.
I am arguing that supporting logic should be as independent as possible of both business logic and I/O, and that best approach is to intercept the invocations of the business logic. Don't intercept the HTTP request; intercept the call to the business logic function, so that you implement interceptors once regardless of how many I/O mediums.
So I'm thinking either (non-http) middlewares or decorators can solve this problem, but before committing, I ask:
- does the aforementioned argument uphold? If not then why?
- is it worthwhile solving this problem? If not then why?
- if so, has it been solved?
- if so, please point me in the right direction. If not, what do you recommend?
*if there is a better term than "supporting logic" please lmk in comments