In a typical imperative application, business logic and side effects are inextricably linked. For example, when you write await db.checkInventory(…), the runtime immediately reaches out to the database. Our Effect System works differently. Instead of performing the action, our functions return a description of the action. When our code needs to check inventory, it doesn’t call the database; it returns a plain object instead, which will be executed later by an interpreter.
Integration tests against a real database can and should still be performed. The idea here is the ability to test business logic in isolation without using mocks. Effect systems also have other benefits. You basically get cross-cutting concerns like logging and profiling for free. Every single database call, API request, and file read in your entire application can be easily logged and profiled.
I am not arguing against an effect system. They can help in certain circumstances. But none of the reasons in the article are one of them. Also the article is a bit lopsided because the real pain with these systems is error handling, resource handling like transactions or parallelism etc.
What you write about the “other benefits” profiling and logging is also not the reason to introduce such a system.
What does an api request has to do with business logic?
It feels a bit as if you just discovered the idea of effect systems and are now trying to justify to use it no matter what. 😉
I think you might be focusing on the execution of the request rather than the orchestration. The decision of when and why to make an API request is absolutely business logic. In imperative code, that logic is hard-coded to the execution. By separating the intent from the execution, we can test that decision flow without spinning up the infrastructure.