You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 .
The text was updated successfully, but these errors were encountered: