What exactly does "run in the browser" mean?

[castedo]

@dionjwa The docs page https://docs.metapage.io/docs says "Metapages are workflows that run in the browser" but it also says "Anything that can be docker containerized".

Am I correct in assuming that the meaning of "run" here does NOT mean containers are run inside a WebAssembly virtual machine? I think this would be extremely difficult to achieve.

If one were to say "metapages manage workflows from a web page user interface", in what ways would this be inaccurate?

[dionjwa]

Hi @castedo, thanks for the questions! And this points to where the explanations can be better (in the process of making some major updates now).

You are correct in that containers are NOT run inside a WebAssembly virtual machine.

The metapage workflow management runs entirely in the browser. The nodes of the workflow, called metaframes, are simply websites (that are connected with data pipes), and one of those metaframe websites runs docker containers.

Where does that docker container run? Currently, there is a public job queue manager, and you plug a worker running on your computer into that queue, so your computer is running those containers (and the server and various bits piping the data to/from the container to the workflow)

Eventually the goal is to run the workflows themselves in headless chrome, so that the workflows themselves can (optionally) be run on the server (but still in a browser context), and still then, the individual container metaframe nodes will be responsible for running the containers.

We are currently building the kubernetes infrastructure to run the containers on our cluster, and open-source it so that any organization with kubernetes can run their jobs containers themselves, we just manage the queues. Kind of like how CircleCI or Github Actions manage the workflow and the compute queue and may run your actual jobs, but you can easily plug your own workers to do the container jobs, saving you $$$. That is the goal for this year.

So:

"metapages manage workflows from a web page user interface" is more accurate, but also, the workflow actually runs in the browser, it's not just an interface. This will change when we run the workflows on our servers, but the key part is that the workflow is still always running in the browser.

I hope that helps, and will update the docs very soon.

[castedo]

Thanks! If I understand correctly when a workflow runs on your servers, the workflow is still running in a browser because it is running in a headless Chrome context.

So there are two interpretations of "in browser". One is running within an end-user context with a full-browser application that can browse the web, render HTML pages on a screen etc... and the second interpretation is a headless session of Chrome on the server.

[dionjwa]

Yes! This way, when you are interacting with the browser, you are editing and seeing the exact same workflow that will run on our backend cluster. There is still some work to be done when there are "duplicates" e.g. the workflow is running on the backend AND in your local browser. For now it won't matter much regarding docker container metaframes, since they will be talking to the same queue, so both versions will know if their configured docker job is running or not, and if not, submit the job. There's still some edge cases to work out there, but that's how it's currently envisioned.