this post was submitted on 27 Dec 2025
9 points (80.0% liked)
Programming
24072 readers
155 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Lol...at first I thought the article wasn't satire until I found the AI part. Well done.
Summary: Hey, let's add another abstraction layer so we don't need to mock these calls, but we don't test what happends in that pesky database call, because we would need to mock that somehow. But now we need AI to handle the abstraction layer.
I think I'll use this article as a basis for discussion for job interviews.
Thanks.
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.