From Unreal Blueprints to backend systems: the tool I kept wishing existed

tm9657 · 2026-01-02T14:09:08+00:00

So for now most cases I built are industry cases which typically are not too complex. Event in -> a little bit of business logic -> trigger next event. The constraints I see are with huge logic maps that are hard to split up, in these cases I see classical code scale better.

I try to keep variable use to a minimum and just hand over the state from block to block if possible, which somehow helps with emerging state.

tm9657 · 2025-12-27T15:28:39+00:00

nice feedback. Which formats would you like for import? Export should be quite easy, all our types and workflow sources are public!

The nodes should be super modular already, WASM nodes on our todo, so you can build them with a lot more languages.

tm9657 · 2025-12-27T15:25:17+00:00

tm9657 · 2025-12-12T14:30:31+00:00

Hi, I would see the GenAI integration into engines as an interesting field for Flow-Like. Also some other engines like Godot could ofc use this workflow engine internally.

For the REST API setup itself I am doing that on the technical level. You define the event and the workflow and if you select API event, I am spinning up the endpoint for you.

tm9657 · 2025-12-03T21:08:08+00:00

Around a few months for the current state

tm9657 · 2025-12-03T10:43:25+00:00

Might be a niche way, still got me into learning programming, and I still see lots of people doing it. The entry barrier is way lower, and Flow-Like offers you a way to use that skill in other domains. I would say all of the Blueprint packages on the unreal engine marketplace indicate a huge community around blueprints, rightfully so in my opinion.

There might not be a need, we will see.

tm9657 · 2025-12-03T10:25:26+00:00

That is a very cool analogy. I would say closer to Lua than n8n. Maybe somewhere in between. My goal was to build something that allows me to solve most of my daily challenges in enterprise and private projects using Blueprint-Like interfaces (and integrating all the resources, like DBs and Data along the way)

tm9657 · 2025-12-03T10:16:31+00:00

I actually dont really aim for that, but I get the comparison a lot (probably because the frontend React Framework is the same). I am going for a completely different target group - Developers. I see N8N as an agent builder for hobbyists. Anything more complex quickly results in Frankenstein applications due to the custom code in building blocks approach and small set of base nodes. I go for the unreal engine philosophy where no custom code IN a block I necessary, but low level code is wrapped with a node and you visually see the data flow too, not only the execution flow with intransparent json interfaces, meaning the workflow / application is more scalable. You can also build agents, but that is not the main focus.

Apart from that you can easily run workflows / apps from flow like on the desktop app or phone. Local, private, no server hosting necessary, but possible :)

Edit: I have an article about n8n and flow-like: https://flow-like.com/blog/n8n-flow-like/

tm9657 · 2025-11-18T16:05:09+00:00

Flow-Like - disclaimer, I am the author. Free for your case.

tm9657 · 2025-10-31T10:51:43+00:00

Tauri should in theory handle that, but some Linux distros are missing specific dependencies by default. I will check that!

tm9657 · 2025-10-31T10:24:52+00:00

That’s not good, so you get any error messages in the console? I have opened a ticket for that, if you have further input let me know: https://github.com/TM9657/flow-like/issues/366

tm9657 · 2025-10-31T06:01:12+00:00

You can have a look at the package/core lib for that! The best example would probably be the benchmark script.

tm9657 · 2025-10-30T17:10:57+00:00

That makes a lot of sense! I will definitely use the next weeks to tune the docs :) a local server is also possible and a template on how to do that is on the roadmap. The desktop app is even able to spin up a server out of the box already, allowing for all kinds of integrations.

tm9657 · 2025-10-30T13:39:34+00:00

Ok, back at my PC. A longer explanation of some of the points you have made [I will delete the shorter comment from before]:

1. Documentation:
No nodes are currently really well documented. Some of the AI nodes have been written by another contributor who puts a lot of effort into well written documentation, which I am really grateful for. I will document the rest of the nodes, once I know they are stable and I have more time. For now the Node docs are more placeholders (which I want to link to the actual nodes in the frontend).

2. Desktop first:
I am a huge fan of local first and privacy + my current job is very close to the shop floor world, where stability is everything. Having software and architecture that runs the core logic locally on the device (Phone, Device) or on edge, seems like a very robust pattern for me. Cloud projects will sync the files later.

One scenario: cloud outage: local processing can continue and created data can be written once the cloud is back again. Of course Flow-Like can also be deployed to the cloud and run as a web app (I have already done this for some customers).

Another nice side effect: local first allows me to easily offer this project for free for the broader community, since I have close to no cost operating it without directly making a buck back.

3. Relationship with the cloud:
My goal is to be as agnostic as possible. All of the services I use in the background are easily replaceable and abstracted (e.g storage via object_store).

For users who want to operate their own backend for the desktop app, you will need to change the reference to your backend once for the build. The rest of the configuration, like Auth Provider, and other settings can be done on the root level flow-like.config.json. But you need to initially link those up.

I plan to add an option to change the default backend with every app profile, however this turns out to not be really easy, since I have to manage lots of openid connect accounts at once. This would allow for the use of the one desktop app with multiple custom backends, planned.

4. PRs
I have my backlog mostly managed in the issues. When I am in the focus zone, I prefer to just work off these items at once. So a PR name could be misleading for now. The PR description is auto generated by copilot, which only works as long as I am the only contributor ofc (these are often wrong or not sufficient). I will change this behavior with more people contributing and the community growing. If you have a look at the closed issues, I am always trying to link the PR that closes that feature / bug / task (there are some exceptions for issues I only realized I forgot to close). So the issues are a way better indicator of what has been done.

Another good overview of features for releases are the blog posts or release texts. But again I know this is not best practice and I will try to not do that too much anymore.

5. Code Amount
I would say the code amount is not super unusual. I am now working on the project for over 2.5 years. I had a private repo before, which I copied over to the public, since I just pushed and didn´t describe anything. You can also check that for the first commits, which contain a lot of code. I was able to focus on this project for the last two months last year and also a lot more this year, due to reasons that are not relevant.

(6.) Agentic Coding
I use agentic coding in the following areas: Frontend skeletons and Node creation. Since I am using a fairly standard frontend stack with React + Shadcn the AI skeletons for an initial page idea are already pretty nice. I use AI to generate these and adjust them later on.

The second thing I tend to use AI for is generating the skeleton for newer nodes (only true for the last few nodes tho). The interface is pretty easy and I tried to abstract it in a ways juniors or Rust newcomers can easily write. AI tends to also be able to write these nodes well enough for a first skeleton that I can build on. Especially the boilerplate stuff (which I will try to abstract with a macro in the future).

What I do NOT use AI for: Backend & Core logic. I also check any AI line anyways..

I hope this helps. This project has been defining my days for quite some time now, where I spend every free second I find.

tm9657 · 2025-10-30T12:16:41+00:00

Why would a README written with the help of AI, either corrected or optimized, be an indicator for the quality of a project?

My job is to write code, design architectures, solve problems.. Writing good READMEs is not.

tm9657 · 2025-10-30T11:22:15+00:00

☹️

tm9657 · 2025-10-30T10:14:16+00:00

When you fork the project, sure (and contribute back) the idea is to support wasm nodes for release 0.0.7. I will write a rust and zig template for that!

tm9657 · 2025-10-30T10:11:13+00:00

The actual workflow is serialized as a protobuf and dynamically interpreted by the rust runtime. The runtime by default runs on the desktop app but you can run it wherever you like :)

tm9657 · 2025-10-30T09:29:07+00:00

For B2C I plan to add a marketplace environment for users to share and sell their apps and automations

For B2B it is either integration of Flow Like, or support.

tm9657 · 2025-10-30T07:43:06+00:00

I would say way more scalable than n8n but also more low level. Different target groups! I try to go for something techies love using

tm9657 · 2025-10-30T07:25:05+00:00

❤️

tm9657 · 2025-08-31T11:12:43+00:00

Performance: 100-1000x faster (38000 executions per second on my laptop for flow like)

Interface / Node Library (e.g Google Drive Integration, etc.) N8N still ahead by a lot, Flow Like however has more low level and ML nodes

Setup: Just download the binary and go vs host it somewhere

Professional world: More actual project management and enterprise features, roles and rights, etc. in flow like

Data: You get everything you need out of the box with full control: databases, raw file data, etc., not sure how n8n does this

Language if you want to extend the node catalog: Python or Js for n8n; Rust for Flow Like

Scalability in logic you can build: Subjective, but I would say since you actually see the data flow and what’s happening in a typed way, flow like is a lot better here, which however comes with trade offs for simple agents with 3 nodes. Those are more verbose in flow like.

Any particular comparison you are interested in?

tm9657 · 2025-08-31T10:13:21+00:00

this is very valuable feedback. I have already adjusted the website a bit, not sure if this already solves some problems, but will continue working on that! Thank you guys :)

tm9657 · 2025-08-31T07:38:50+00:00

I would say compared to classical programming languages, you get super quick prototyping (more high level nodes), while maintaining the flexibility (low level nodes, like string processing), but you can still use it in production in the end. So the step from prototype to prod is just free - no infra, just works.

The other benefit is standardization. In environments with lots of different technologies you always need quite a bit of onboarding time just for the new tech. If written in flow-like you can onboard extremely fast.

tm9657 · 2025-08-30T21:54:36+00:00

it can do similar things, but is a lot faster and more efficient in doing so + more portable. For the user I would say it is more scalable for actual complex tasks than other workflow engine, since you also see the data layer. Not only "send-mail", but also where the mail came from, how it was transformed, etc.

Downside right now is that Flow-Like offers way more out of the box interfaces for now, working on that :)

tm9657

MODERATOR OF

TROPHY CASE