Ambient VS fp-bindgen

Hi, this is Kuba from Ambient team, I work on Ambient backend.

The servers in question are part of the main Ambient application [0]. The server part is open-source just like the rest of the engine. You can start your own server using native build of Ambient (check cli help for `ambient serve`).

As for the orchestration and creating servers on demand, we are using Kubernetes and Agones [1]. Both of them are open too. We just have a thin API server that receives requests that a server is needed, checks if there's already one running and if not it uses Agones to allocate one.

[0]: https://github.com/AmbientRun/Ambient

Intriguing development! It's quite refreshing to witness Bevy hopping onto the WebGPU bandwagon. I can't help but wonder about the complexity involved in transitioning an existing codebase from WebGL to WebGPU in such a compressed timeline.

On a similar note, Ambient (https://github.com/AmbientRun/Ambient) has been on my radar for their utilization of WebGPU, though they seemingly lack a tangible web demo. Anyone have any insights or comparisons to share?

- Finally, our UI framework, Ambient UI, can now be used from guest code. Combined with our networking and ECS, this unlocks an exciting new capability: multiplayer UI!

In the blog post, we walk through the creation of a basic multiplayer beat sequencer using these features. We're excited to see what else the community can cook up :)

- Download: <https://github.com/AmbientRun/Ambient/releases/tag/v0.2.0>

Download: https://github.com/AmbientRun/Ambient/releases/tag/v0.2.0

I work on Ambient, an open-source platform for streamed[1] multiplayer games written entirely in Rust. We're a Swedish startup that supports remote and we're hiring for self-starters - if you think you can flourish in a startup environment, feel free to apply!

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