There are many environments that don't support WASM yet. Plus, JavaScript is a lot lighter weight for some things - particularly if you just need to register a bunch of callbacks that process data when events come in. I'm using WASM too quite a bit, though! Try out tinygo, gopherjs, or Go's built in wasm/wasi support for that.
This uses a "reactor" mode I added to quickjs recently which exposes quickjs as a wasi library instead of a traditional main() loop. This allows the host environment to call loop_once() to step once through the JS event loop, and poll_io() to check for I/O. This way, if there's nothing available to do (VM is idle), the Go host environment (or js) can sleep until some I/O arrives. This is a lot more efficient than having Js poll for I/O.
Really interesting, I’m currently using https://github.com/fastschema/qjs but would love a bit lower-level control like your reactor and Go library provide.
loop_once may have been called run_microtask if I understand the “loop” boundary correctly?
Is there a way to be more granular in execution? Like running a single “basic block” (until a jump) or until next function call?
Try this! It works going the other way, just use esbuild to target ES2020 before you run in it. If you want to transpile to Go that's also interesting, probably tsgo's ast parser can be leveraged to do that. See: https://github.com/aperturerobotics/go-quickjs-wasi-reactor
But it was too graphql-coupled and didn't really take off, even for my own projects.
But it might be worth revisiting this kind of protocol again someday, it can tag locations within a JSON response and send updates to specific fields (streaming changes).
protobuf-go is a widely used binary serialization library and IDL for protobuf in Go. The upstream library leverages reflection to provide a wide variety of features which are useful in a server context.
Go is increasingly being used for resource-constrained environments like embedded (tinygo) and WebAssembly. In these environments, reflection is not always available, and when it is, it adds significant weight to the binary size.
vtprotobuf: https://github.com/planetscale/vtprotobuf - compiles static code generation for Protobufs in go, including functions to marshal, unmarshal, size, clone, messages. However, it still requires protobuf-go and the reflection-based code for the message structs.
protobuf-go-lite takes this one step further with a stripped-down version of the protobuf-go code generator modified to work without reflection and merged with vtprotobuf to provide modular features with static code generation for marshal/unmarshal, size, clone, and equal. It bundles a fork of protoc-gen-go-json for JSON support.
Dynamic configuration of components. It uses a system of communicating controllers which is more flexible in terms of runtime reconfiguration. libp2p is an excellent project and can be integrated into Bifrost's system as a library.
Check out the repo on GitHub as well as the others on the same GitHub organization! Also feel free to join discord and ask questions or shoot me an email. https://aperture.vision
Hi, author here. Thanks for checking out Bifrost. The short pitch is: any protocol over any transport with seamless cross-platform (browser <-> native) communication.
Building internet applications often involves writing code that is tightly integrated with the choice of communications transport, for example, one has to make the design decision to use either WebSockets or WebRTC, and then all other design decisions are driven by that.
Bifrost aims to allow developing applications without knowing or caring which protocols are used under the hood. The app can just say "Open a stream with peer X" and whatever configured transport(s) make that happen.
I'm still working to improve the docs and new user experience, if you have any suggestions on how I can make it easier to understand, I'd greatly appreciate it!
I see, thanks. I think it would be useful in the docs to describe both some less technical as well as some technical examples of useful applications of your work.
Do you have some examples of _concrete problems_ that would be easily solved with this? If so, mention them.
Telling folks about technical aspects doesn’t help advertise your work unless you can help a new reader relate it with their own experiences or problems.
Bluetooth could work! Just need to implement the Transport interface.
Peer discovery is not implemented at the moment but could easily be added (and will be soon). Here's how: any controller can resolve EstablishLinkWithPeer. A peer discovery controller could compare the list of discovered peers with the list of desired connections and initiate connections via UDP when there's a match.
Signaling is managed by the Link implementation. For UDP we use quic-go.
This stack could be the basis of a software to share things no matter your connectivity situation.
You fire it up, it scans things around. Local network? It uses that. Not local but internet, it uses that. Nothing but BT, you can still detect people around, chat and exchange files.
People could be identified by public keys and that's it, not need for an account, signaling done by zeroconf/bt-scanning/bittorent.
Basically a solution to the current chat nightmare.
But the amount of work is overwhelming, even with this.
There is a design for routing in the repo (and tor-like circuits). However it is not implemented yet. I'd love to grow the community and have more people collaborating on this.
