gabigrin

Wow :)

Working on a 1.0.0 launch for Flyde - https://flyde.dev/, an open-source visual programming language. It works great for embedding visual AI flows for backend logic. Integrates with TypeScript code, runs on VSCode & Node.js (via a runtime library, in-repo, no containers needed)

Would love to chat with people looking to combine n8n-ish capabilities in their code!

You theoretically could. Not sure it's the right tool for the right job.

We believe that many programming tasks are better done with textual coding.

Interpreting Flyde (the visual programming language behind Flowcode) flows and running them (see https://github.com/flydelabs/flyde/blob/main/core/src/execut...) ) will not benefit from being visual. It's mostly synchronous, borderline fractal logic.

A great use case for visual programming would be a task that involves several LLM calls, third-party vendors, and some transformation logic on top.

Looks like it! Best of luck with midio.com, looks like a great product.

OP here. At least a dozen times :) He was the inspiration of starting to work on https://github.com/flydelabs/flyde, the visual-programming language powering Flowcode.

Nope - we're both visual nodes-and-wires based tools, but they create a visual representation of your codebase/architecture, while we allow you to create the applicative logic visually.

Thank you!

I checked your project, loved the idea and implementation! Played with it a bit, was very slick. Going to read the paper soon. Congrats

PS1: A poster about Flyde, the visual-programming was accepted to VL/HCC 23 - https://conf.researchr.org/details/vlhcc-2023/vlhcc-2023-pos... PS2: We call our AI copilot "Flowpilot" as well :D

Node-RED is a great tool, especially for IoT and pure automation use-cases.

It's far from ideal when it comes to integrating with existing codebases and building backend features.

We're not competing with it directly, as we're aiming to be integrated into applicative production workflows.

Re: docs, 100%, it needs tons of improvement.

Error handling is a first-class citizen in Flyde, the visual programming language powering Flowcode. Any node has an "output pin" called "error" that will emit data if something goes wrong.

You can test this real quick in the playground - throw in a JS expression and write some gibberish and test your flow. Alternatively, use the HTTP node with a non-existent URL

Thanks for trying Flowcode! sorry it didn't work for you.

The AI should have explained that local scripting isn't supported by Flowcode. Our copilot is under active development and has a lot of room for improvement.

Flowcode is built for cloud-based use cases - you can think of it as a "visual serverless" platform

Perhaps working directly with Flyde https://github.com/flydelabs/flyde + some AI assistant to build the custom nodes you'll need might work for that use case.

Hey, author here. Thanks!

When I started Flyde, the underlying visual programming language powering Flowcode, I went for DOM as it was the simplest solution to get something working. I was sure a rewrite to WebGL/Canvas would be needed to be performant, but we managed to render pretty complex flows and leverage the ever-growing React ecosystem. Also, react-flow was in its infancy when I started, but even later, as it evolved, I still prefer to have full control over the experience. I strongly believe that the editor and the ergonomics of the "language" are inseparable, and if you want to build something truly great, you have to control the experience end-to-end.

I do think one day WebGL/canvas might be required to take the editor to the next level. One example I always think of is this one - https://xai-primer.com/tool/ It's a great UX solution for nested flows (something Flowcode supports). But as long as I can stay with DOM, the better.

Re: deepwiki - thanks for that! very cool website and LLM usage

OP here.

I'm obviously as biased as one can get here, and have a general sense of agreement with your sentiment, but I think it boils down to 2 aspects: 1. The nature of your code. For a linear, synchronous algorithm, no doubt text is the way to go. For async, concurrency-heavy workflows, debugging it in a linear fashion becomes a nightmare. Take an LLM-heavy backend workflow for example, with calls chained and running in parallel. Horrible to debug using textual code.

2. The experience and features set of the editor itself. Making it reactive and not imperative was exactly our goal. Flyde, the visual-programming language powering Flowcode is a functional-reactive visual-programming language. Control-flow is determined by data, unlike existing tools in that space where arrows represent control-flow and all of the dynamic variables are hidden inside implicit "${{node1.input2}}", making it as far from Unix philosophy as it gets.

Also, Flowcode supports custom code in 3 ways: inline code expressions, custom code nodes (you can even fork any of the "stock" nodes with complete access to the underlying API), and codebase SDK integration, so you could supply it with inputs from your code in a typed way.

Author here. Thanks!

Lowering the barrier of collaboration is indeed a major goal for us. In the DRAKON analogy, Flowcode might help technical product managers collaborate with developers on LLM-heavy logic.

Re: vibe-coding - that matches our vision 100%. Let AI build the nodes while a human (even if heavily AI-assisted) oversees

Great reference! Even mentioned it on Flyde's launch on HN - https://news.ycombinator.com/item?id=39628575

We imagine 3 use-cases with Flowcode: - Non-developer, but technical roles (IT, Automation experts) using it as a more powerful and flexible alternative to n8n.io/make.com - Technical product managers using Flowcode to integrate AI-based flows into their product and collaborating on them with developers - Experienced developers building LLM-heavy (or any other async/concurrent heavy logic actually) looking to build faster flows

Haha, thanks!

As for the DOM nodes - as a React frontend developer by trade, the DOM was my first choice for simplicity when I started working on Flyde a few years ago.

I was sure I’d eventually need to switch to Canvas or WebGL, but surprisingly, the DOM has held up pretty well. It’s been performant enough to render complex flows smoothly, and being able to leverage the existing React ecosystem has been a huge advantage.

I do think there's an option for a canvas/WebGL based version in the longer-term future, especially to be able to build interactions like this one - https://xai-primer.com/tool/

Amen!

Thanks!

For sure! my son ended up learning how to refresh haha. Gonna push that soon. And yeah, emojis are randomized each session to foster discoverability

Thank you! The main website (https://www.myphotos.site) was built my co-founder Or using Webflow. He's a real pro when it comes to websites - see more of his work here https://gambit.design/

The user galleries and the editor dashboard are built using Next.js, Typescript, Tailwind, and Vercel. For the masonry, we first tried a few libraries (such as https://www.npmjs.com/package/react-masonry-css) but ended up writing our own because all the libraries we tried didn't handle proper column-height distribution.

Anything else you're curious about?

Great feedback! Not just great, but 100% made sense to go ahead and ship it real quick. It's live! https://youtu.be/qhHHPHDnMTc

(and server-side secure!)

Yeah, you're right. We're gonna fix the images ASAP. They are indeed embarrassing. Also, the term "guides" is misleading as it sounds like documentation, which it isn't.

Thanks for the feedback!

The "give users full control" vs. "help the user reach a fine result" tension is real. Our take on that is allowing pro-users who want full control to embed their gallery in their website. We can't nor want to compete with full-blown website builders on customization features.

That's a valid point. We're still experimenting with pricing and this is great feeback

sounds relatable :D

Will do! thank you

The session is active for couple of hours IIRC. Once the user is done with the selection we upload the images to our servers (Supabase storage) and delete the GPhotos session.

No, the Google Photos integration is uni-directional. We only get access to images users pick in the import phase. Removing images from MyPhotos is done from the platform itself. Regarding retention - we'll delete all your data if you wish to cancel your account.

That's cool! thanks for sharing

Thanks! We're using the Google Picker API - https://developers.google.com/photos/picker/reference/rest You create a picker "session" which is a link where the user can select images from Google's side. Then you poll the session and once the user is done, you can get access to the media items (imgs and videos) that the user selected.

At first, we wanted to auto-sync galleries and were bummed by the way this API works, but tbh it ended up being more private and secure for the user (no auto-syncing that embarrassing picture that shouldn't be online) and helped us avoid implementing a picker on our end.

It's far from ideal but if you search for an album, you can quickly select all of it. Here's a video of Or, my co-founder showing that - https://youtu.be/7gi58SuQ6Rk?si=LQu8fJBDflVR11Rs&t=38 (links to the exact second)