You can handle complex branching using standard JavaScript. Since every pipeline is just a function returning data, you can use if/else or map to return different sub-pipelines and commands from within your logic functions. Here's an example:

const processUsersFlow = () => 
  effectPipe(
    fetchAllUsers,
    (users) => {
      const tasks = users.map(user => {
        if (user.isAdmin) return syncAdminPermissions(user); // Sub-pipeline
        if (user.isGuest) return cleanupGuestAccount(user);  // Sub-pipeline
        return notifyUser(user); // Simple Command
      });

      return Parallel(tasks); 
    }
  )();

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.

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.

You can still test the functions individually or run the entire flow against a test database, but without an effect system like this, it's very hard to test business logic in isolation.

I've added JSDoc type annotations to the library.

Author here. In my experience, AI coding tools like Claude Code can write code in the Effect system style, and that could be a great starting point for getting developers not familiar with this approach on board.

I considered adding JSDoc type annotations, but that would make the code a bit verbose.

I think this page explains it well: https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch

Perhaps I was unclear. What I meant to say is that, whenever possible, we shouldn't have multiple versions of a field, especially when there is no corresponding plaintext password field in the database, as is the case here.

Thanks for the tip. password.trim() can indeed be problematic. I just removed that line.

Seriously, why the negative tone? If I've offended you, I'm sorry. You might think that I'm wasting time, but there are multiple ways to skin a cat. I prefer not to use DEB packages for deployment, though others might.

Cleanup can be as simple as deleting the latest deployment directory, if the script gets that far. The article is about using built-in Linux tools for 'easy' application deployments. One can also use dedicated tools, as you suggested, to further automate the deployment process.