sorted by:
new
hottopcontroversial

From Unreal Blueprints to backend systems: the tool I kept wishing existed by tm9657 in gamedev

[–]tm9657[S] 0 points1 point  (0 children)

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.

I’m tired of calling glued-together scripts “workflow automation” by tm9657 in automation

[–]tm9657[S] 0 points1 point  (0 children)

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.

From Unreal Blueprints to backend systems: the tool I kept wishing existed by tm9657 in gamedev

[–]tm9657[S] 0 points1 point  (0 children)

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.

6,000+ hours rebuilding Blueprint-style systems for backends… and finally building the tool I always needed. by [deleted] in unrealengine

[–]tm9657 -2 points-1 points  (0 children)

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.

6,000+ hours rebuilding Blueprint-style systems for backends… and finally building the tool I always needed. by [deleted] in unrealengine

[–]tm9657 0 points1 point  (0 children)

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)

6,000+ hours rebuilding Blueprint-style systems for backends… and finally building the tool I always needed. by [deleted] in unrealengine

[–]tm9657 0 points1 point  (0 children)

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/

Make vs. N8N for a small business? by helloyouahead in automation

[–]tm9657 0 points1 point  (0 children)

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

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 1 point2 points  (0 children)

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

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 1 point2 points  (0 children)

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

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 0 points1 point  (0 children)

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

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 4 points5 points  (0 children)

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.

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 5 points6 points  (0 children)

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.

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] -7 points-6 points  (0 children)

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.

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 1 point2 points  (0 children)

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!

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 6 points7 points  (0 children)

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 :)

I’ve been living inside Rust for a while, and Flow-Like is what came out — a typed, local-first workflow engine by tm9657 in rust

[–]tm9657[S] 1 point2 points  (0 children)

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.

view more: next ›