wasmi VS fp-bindgen

There are lots of solutions to this, I was randomly looking into this yesterday purely out of curiosity and it looks to me like wasmi is the current go-to option.

Hello guys, i was looking for a no std wasm interpreter and i found out about wasmi: https://github.com/paritytech/wasmi/, but when i tried it i get an error module env not found. I suspect that in my program i call an extern function putchar() to be able to print and wasmi doesnt support that, but other interpreters i tried support it, for example wain. Are there any alrernatives, or am i doing sth wrong here. I dont have a deep wasm knowledge, i was just wanted to experiment with wasm in a no std enviroment. Heres my code:

fp-bindgen is a library that can help you if you to write custom plugin APIs for such a use case: https://github.com/fiberplane/fp-bindgen

Yep, you're right. For this, there are a few options. The ones most relevant to you are fp-bindgen, which targets Wasmer, and wit-bindgen, which targets wasmtime.

1. Integrations with some of the most popular open-source observability tools: Prometheus, Elasticsearch, Loki, and more integrations with other tools are on the way.

2. A WASM-based plugin system for integrations (which, in the future, will allow for 3rd-party integrations to be built and run securely) along with an open-source bindings generation framework https://github.com/fiberplane/fp-bindgen

3. An advanced block-based editor: You can run PromQL, LogQL, and Lucene queries, and display Prometheus charts and Elasticsearch or Loki log tables alongside the rest of your content. Filter your metrics, and logs, highlight important records, and collaborate on your infrastructure data.

4. Templates are written in Jsonnet language and allow you to programmatically create notebooks and automate your Fiberplane workflows. They can have Webhook URLs attached to them allowing you to connect Fiberplane with your alert tools (or really anything that can send a Webhook request) making them a powerful tool for incident runbooks and post-mortems.

5. A CLI that allows you to share your terminal debugging output with your team with a simple command.

6. Our backend is all in Rust, using the Axum web framework. It also includes some fun parts like a custom Operation Transformation library that’s used directly from the backend and compiled to WASM for the frontend.

Fiberplane was created out of our own experience of running large distributed systems. There was too much context switching when working with monitoring and observability tools. Over the past two years, we’ve been working hard on the first real-time collaboration notebook for the observability space to make infrastructure debugging faster and easier.

We’re launching into public availability and looking to create the best debugging and incident resolution workflow tool for developers, Site Reliability, and DevOps engineers. We would love your feedback.

Why did you choose wit-bindgen over fp-bindgen? fp-bindgen seems to be better suited for Rust-to-Rust communication.

Checkout https://github.com/fiberplane/fp-bindgen