A Capsule application is a runner (or launcher) of wasm functions. Capsule HTTP can serve the functions through HTTP (it’s possible to use Capsule as a simple CLI with Capsule CLI). And soon: NATS and MQTT
Yomorun is a golang project that provides a super fast quic web transport with polyfill / fallback to websockets . It’s 100% golang with a dash of wasm / tinygo
it’s using wasm / tinygo as it’s serialisation codec
I raise this because nats is great but not for the gui layer . Yomorun looks like a great way to keep a gui updated off nats inboxes etc
woukd just need a yomo proxy / bridge of sorts that gets data off a nats topic .
I suspect there are other uses for it too .
Also the task file approach is very nice way to allow users to model their computation graphs and flows. See the examples folder !
y3 ( their wasm based code ) is a bit like data frames in that you can read a stream of data continuously over quic / web transport.
There is no need to do code gen for your types because it’s a low level encoder of primitive types. Quite clever and useful .
the zipper is a way of describing flows of one wasm ( or non wasm ) golang function into another . A DAG of sorts.
Yomorun is crazy fast but it has no durability . So if a service is down it won’t catch up later when it’s comes back up later.
Hence why it could be bridged to nats if durability is needed . GUIs tend to not need durability :)
There is sone synergy / low hanging fruit here .
but my main reason for raising this is because yomo would fit in very nicely as a visualisation gui to have a user lever view onto the capsule computation graph.
There is probably a way to take any golang strict and “ reflect “ it into a yomo y3 type. Or even just use the t3 type in capsule as a base codec / serialisation system . Then you get screaming fast setiakisation with a gui for visualisation
Hope this long ramble is not too confusing … either way it would be great to hear your thoughts on the ideas raised and the applicability of Yomorun for the use cases I raise :)
Yomorun is a golang project that provides a super fast quic web transport with polyfill / fallback to websockets . It’s 100% golang with a dash of wasm / tinygo
it’s using wasm / tinygo as it’s serialisation codec
I raise this because nats is great but not for the gui layer . Yomorun looks like a great way to keep a gui updated off nats inboxes etc
woukd just need a yomo proxy / bridge of sorts that gets data off a nats topic .
I suspect there are other uses for it too .
Also the task file approach is very nice way to allow users to model their computation graphs and flows. See the examples folder !
y3 ( their wasm based code ) is a bit like data frames in that you can read a stream of data continuously over quic / web transport. There is no need to do code gen for your types because it’s a low level encoder of primitive types. Quite clever and useful .
the zipper is a way of describing flows of one wasm ( or non wasm ) golang function into another . A DAG of sorts.
Yomorun is crazy fast but it has no durability . So if a service is down it won’t catch up later when it’s comes back up later. Hence why it could be bridged to nats if durability is needed . GUIs tend to not need durability :)
There is sone synergy / low hanging fruit here .
but my main reason for raising this is because yomo would fit in very nicely as a visualisation gui to have a user lever view onto the capsule computation graph.
There is probably a way to take any golang strict and “ reflect “ it into a yomo y3 type. Or even just use the t3 type in capsule as a base codec / serialisation system . Then you get screaming fast setiakisation with a gui for visualisation
Hope this long ramble is not too confusing … either way it would be great to hear your thoughts on the ideas raised and the applicability of Yomorun for the use cases I raise :)
https://github.com/yomorun/yomo
the cli repo is old. It’s now inside the yomo repo itself .