Discussion: how EmbeddedFlyde run the flow?

[linonetwo]

website/src/components/EmbeddedFlyde/EmbeddedFlyde.tsx

How did it run the flow, and load the deps? The code is a bit roundabout, I can see it load JS object from @flyde/stdlib/dist/all-browser, but can't find where they are used, and I can't find where the flow is executed.

BTW, Maybe you should enable Discussion in this repo.

[GabiGrin]

As mentioned in #28, it's not the main focus of Flyde right now, therefore I'm not investing in documenting it. This makes this discussion a great place to elaborate.

EmbeddedFlyde was a quick-and-dirty adaptation of Flyde to the web, to enable the online playground.

Moving Flyde to execute on the web posed 3 challenges:

1. Loading .flyde files from a browser environment, along with any potential dependencies. It is a process that relies on the filesystem
2. Exposing the "parts catalog" when users try to add a new part. On the VSCode extension, this scans the file system for Flyde files and flyde packages exposing flyde parts.
3. Making the remote-debugger work, as its main implementation is web-sockets based

The solutions were:

1. A webpack loader that runs on the build phase and prepares loads a flow and its dependencies. See Browser runtime #28 for links
2. This is where @flyde/stdlib/dist/all-browser is relevant. It substitutes scanning the file system (as done here) with a hard-coded approach as seen here https://github.com/FlydeHQ/flyde/blob/main/website/src/components/EmbeddedFlyde/EmbeddedFlyde.tsx#L192
3. Luckily Flyde's modules are loosely coupled, so I could easily plug in an in-memory implementation - https://github.com/FlydeHQ/flyde/blob/main/website/src/components/EmbeddedFlyde/createRuntimePlayerDebugger.ts

[linonetwo]

1. I don't think we should load the file uaing webpack, This means workflow is Hard coded in the server side.

Instead i think it's possible to pack the parser to the environment and parse the incoming yaml string as a graph object on the fly.

I think this is what noflo does.

[linonetwo]

2. I see, This is how i can eval js string or load esm from http, to get this list of plugin object, and pass them to you.

I even think this should belong to the core, instead of just be in a demo page.

[linonetwo]

3. When talking about debugger, do you mean The green light appear on the executing step and the history value on hover tooltip?

I like that design and that can be a major improvement compare to the noflo.

This may need a refactor to the adapter design patern, but I'm glad to see it is working now, and i think i can just use it.

[GabiGrin]

1. the webpack is only needed to load the flow client side. On the server side you have the regular loader (@flyde/runtime). The YAML is not the problem, the dependencies are. Flyde allows you to manage code dependencies in a way that is agnostic to whether you're running on the server, client, or microwave. Because dependency resolution relies on the file system, the only way I see doing that is by converting the whole dependency management to ESM. As Flyde's current goal is to be a tool that novice developers can use to build their projects and not an embeddable web-based platform, I prefer not to focus on this right now.

2. Not sure I follow. The @flyde/core's only responsibility is running Flyde flows. It doesn't, and shouldn't do anything else. If using Flyde flows in a web environment becomes a popular use case, I will definitely consider extracting the logic in the demo to it's own package (or adding it to @flyde/resolver), but as explained in the previous section, it is not the focus right now

3. Thank you! and not sure wdym by the refactor. I see little value in refactoring things only for the sake of conforming to a pattern, but as a solution for a possible problem. If there's a problem the current design imposes, I'd love to discuss solutions. If a specific pattern is a good valid solution, then hell yeah.

[linonetwo]

Get it, I'm going to run it on client/server mode for now, but in Electron, so the client talks to the server using electron ipc. Just let the user edit the flow on electron renderer process, and generate yaml, send the yaml to server using ipc when saved. Then ask the server to run the flow.

About the debugger, I'm probably letting it communicate to the server using ipc too. So communicate pattern will have client/server, client/client, client/ipc-server, this is better to be written as an adaptor, but you can wait until my code is done to consider this.

[GabiGrin]

Let me know if that answers your question