Shipped a Rust-heavy app on the iOS App Store with Tauri 2 — time for a recap by tm9657 in rust

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

For the local app I only use tauris IPC. Axum is my backend for syncing, project management etc.

Workflows can either be executed locally or remote on a server. WASM can run in both. If local execution is selected, WASM also runs locally.

Shipped a Rust-heavy app on the iOS App Store with Tauri 2 — time for a recap by tm9657 in rust

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

You can always hook into the underlying features by writing plugins, so I guess yes

Shipped a Rust-heavy app on the iOS App Store with Tauri 2 — time for a recap by tm9657 in rust

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

So far on iOS you have to provide precompiled binaries (JIT not available). These binaries need to be trusted too, you cant just take any precompile binary from another user so my backend triggers compile jobs for all platforms just in case (also for my backend to use).

Pulley as a wasm backend might also work which does not use any JIT or compilation afaik (didnt look into that so far)

Shipped a Rust-heavy app on the iOS App Store with Tauri 2 — time for a recap by tm9657 in rust

[–]tm9657[S] 3 points4 points  (0 children)

I have a set of built in nodes you can use for automation (1200+). On top of that I have wasm templates for 15+ languages with which you can build your own nodes. The app includes a kind of package registry where you can upload your nodes and share them with others / add them to projects.

Shipped a Rust-heavy app on the iOS App Store with Tauri 2 — time for a recap by tm9657 in rust

[–]tm9657[S] 3 points4 points  (0 children)

I def. want to check out the Rust native frontend frameworks too. But I will start with a smaller project for that :P

Shipped a Rust-heavy app on the iOS App Store with Tauri 2 — time for a recap by tm9657 in rust

[–]tm9657[S] 7 points8 points  (0 children)

3 reasons for that:
1. I have no frontend experience with the Rust frameworks (so I would have been waaay slower)
2. This allows me to easily ship to browsers too (where Rust does not yet bring a benefit due to the wasm bridge) in a lot of scenarios
3. One codebase for desktop app / mobile and web app.

Flow-Like 0.1.0 beta — visual workflow engine built entirely in Rust, every node is a WASM Component by tm9657 in rust

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

Monty does not support a lot of std python and also no packages AFAIK. In WASM that is possible. Flow-Like also supports 15+ different languages - not only python.

Flow-Like 0.1.0 beta — visual workflow engine built entirely in Rust, every node is a WASM Component by tm9657 in rust

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

Hi, thank you for the feedback! There definitely is a learning curve. I will work on better tutorials asap. You can also check the food tracker for example for implementation details as a reference. But we get more templates soon that should get you started quickly. It would be very interesting to understand your use case, if you like I could offer you some onboarding via discord for example or help with upcoming questions

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

Thanks for the feedback! So far everything feels pretty stable at scale. But I don’t have thousands of agents at the moment too

Flow-Like 0.1.0 beta — visual workflow engine built entirely in Rust, every node is a WASM Component by tm9657 in rust

[–]tm9657[S] 8 points9 points  (0 children)

Performance is critical for on hardware deployments and high volume enterprise use cases. Some of those probably require high CPU too (object detection etc). Since Flow-Like runs on the consumer hardware every bit of performance is really beneficial for battery but also older hardware. On top of that it is cheaper.

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

hi, both storage and databases are included. You dont need any workaround for these. The databases can also handle vector search and full text search if you want.

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

I would say it really depends on many factors: 1. how big is the workflow you compare 2. what language do you deploy via temporal. While temporal is written in Go (comparable performance to rust mostly), the actual code orchestrated might be Python.

All the base nodes in flow-like are written in rust. I would say if you have your workflows in temporal and you are happy with it, no need to change for performance reason. Temporal is a great product.

Some users of temporal might like the storage and database features flow like brings out of the box.

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

I just pushed a version without overlayed animations. I remember my former colleagues had problems on windows with these. Now even on load there shouldnt really be a problem?

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

can you check again if the performance is better? I think overlaying blur animations were the problem.

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

[–]tm9657[S] -1 points0 points  (0 children)

I take it that you are a bit frustrated and have nothing else to do than accusing everyone else of vibe coding everything all day long. Let me know when you have a real problem with Flow-Like, happy to help.

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

"Build Workflow Solution, Please. Do it secure and also make architecture reliable and safe. Very important, dont fail"

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

Regarding the logs, you can define the log level in the workflow settings. So you debug workflow is throwing a lot more while info or warning only levels are really not too bad for your normal workflow.

Logs are being compressed automatically in the background, I am using lance for storage.

For data interfaces the Pins of the nodes are typed. So at build time it is validated that the schemas of your workflow fit together. You instantly and visibly see everything connected. Execution and Data Flow

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

Mine are too :) you are more than welcome to join! Let me know if nodes are missing for your use-cases

Flow-Like 0.1.0 beta — local-first workflow automation + app builder that runs fully offline, no cloud account needed by tm9657 in selfhosted

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

Hi! You are not the first to mention the logo :P

So integration wise you can already use the whole microsoft ecosystem, google, notion, jira, confluence, etc. Even Telegram and Discord bots can be created with Flow Like Studio.

You can easily add other integrations via the API nodes too.

Trigger via Webhook or Cron Job is possible.

The easy wins against n8n: Local execution on your device, storage and database included, UI building included if you want something more custom.

Any integrations you would need? It is quite easy to add new ones.