[zazaulola]

Explain to me what tasks can be solved in the approach with flows? I used Node-Red in some automation processes. I managed to solve only simple problems that are easy to solve without AI. But how do you program in this style? What does the flow style look like, for example, a program to find the shortest solution of a sokoban or game 15?

PS. Usually, when I need to make all photos in the folder black and white, I use imagemagick.

[monica-guli]

Great question — and I completely agree with your experience. Most flow-based tools like Node-RED or n8n are great for simple, event-driven tasks — but once you try to model anything non-trivial, like search algorithms or puzzle solving, they tend to fall short.

OOMOL takes a different approach.

Each node is a fully programmable unit — you write full Python or Node.js code, import pip/npm libraries, manage state, and do whatever logic you want. The flow just connects these pieces in a modular way.

So when it comes to problems like solving Sokoban or the 15 puzzle, it’s not about drawing a visual BFS graph — instead, you might structure it like:

- One node to define the state structure - One node to generate next states - One node to manage a queue (e.g. in memory or Redis) - One node to evaluate whether the goal is reached - And inside the node code: your BFS or A* logic

In this sense, OOMOL doesn’t force you to express logic visually — the *code is the logic*, and the *flow is how you organize and compose that logic across tasks*. Think of it as “wiring together programmable building blocks” rather than trying to drag-and-drop logic trees.

That said, you raise an important point: *for many simple tasks — like batch processing images using ImageMagick — scripts or shell commands are 100% the right tool.* OOMOL isn't trying to replace that.

Where OOMOL helps is when: - You have multiple steps to coordinate (e.g. conditionally processing based on metadata) - You need to integrate with APIs, databases, or cloud storage - You want to track, retry, or debug failed tasks - You’re composing reusable automation pipelines that grow in complexity over time

In short: > *Not every task needs a workflow engine — but once you start composing real logic across systems, code + flow gives you both power and structure.*

We’re still early and figuring out how to best serve developers like you — really appreciate you pushing on this distinction. Would love to hear what types of things you’ve tried to automate, and where tools like Node-RED started to fall short.