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.

Examples: Express, Spring, Rails, Flask, Laravel, Gin

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:

  1. does the aforementioned argument uphold? If not then why?
  2. is it worthwhile solving this problem? If not then why?
  3. if so, has it been solved?
  4. 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

New contributor
bsapaka is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

bsapaka is a new contributor. Be nice, and check out our Code of Conduct.
 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.