ereslibre

TOP GIT is a community to share interesting open source projects! You can join the Telegram channel on your language to stay tuned and have some treats from time to time!

In this article, we will introduce Wasm Workers Server and we will describe how it empowers developers. We will show you how you can swiftly start using Wasm Workers Server with Docker Desktop. You will understand what are the benefits of embracing this new technology, and you will be able to experiment with a few easy to run, practical examples.

> I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth.

(Wasm Labs dev here) We haven't yet measured performance in a meaningful way that we can use to compare, mainly because our PHP builds also have certain limitations mentioned in the article, such as not having OPcache available at PHP. It is however an iterative process, and we are interested in this, as well as we understand that it's interesting for the community.

> Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime library initialization. Does it work any differently when it comes to WASM?

It's a little different in Wasm, in the sense that there is no need to fork/exec (if talking about bare CGI). The PHP executable gets loaded into the runtime once (what will compile it from Wasm -> native ISA), and then for every request we create a Wasm execution context, and run the PHP Wasm module that interprets the PHP script.

Creating a Wasm execution context is certainly much lighter than a fully fledged fork/exec.

The webassembly-language-runtimes is focused on providing WASI-based language interpreters, what would require a WASI polyfill at the browser level (https://wasi.dev/polyfill/) and (https://github.com/bjorn3/browser_wasi_shim).

Pyodide is certainly another option, but is emscripten based, not based in webassembly-language-runtimes or WASI.

WebAssembly is a binary format executed in a virtual machine. By default, the execution is isolated from the host OS, so that there is no concept of syscall to the OS directly from your WebAssembly module. The WASM module calls to certain exports (the WASI layer) whose endpoints are implemented by the runtime. However, the runtime in this case has the ability to decide whether and how this call that would correspond to a syscall directly had it been run on the OS directly will be mapped to the OS in reality. You might want to map that to a syscall on a real OS, or the Wasmtime runtime could be running in an embedded environment where there is no OS as we might otherwise assume.

WebAssembly also allows for powerful constructs like the component model, where components written in even different languages can interact between them.

Portability is one of the core features of WebAssembly (Wasm) allowing you to run modern applications in environments you could not before. Add sandboxing and security features to the mix and WebAssembly turns out to be a great platform to run applications in the browser and outside of it.

Apache httpd is a modular web server that powers 31% of all websites you access every day. One of its most compelling features is the ability to extend it with new modules. Developers can choose among different modules to add or remove features like CGI, TLS, PHP, and many others.

Today, we announce a new Apache module to run WebAssembly modules: mod_wasm. This module opens a new set of possibilities as many languages and projects can run securely in Apache.

I wanted a different approach for this project when I started it, so what I knew was that I wanted to create a very narrow scoped Kubernetes as a service, that users can run on their infrastructure as easily as possible.

One thing that I knew oneinfra wouldn't do, funnily enough, was to create or manage infrastructure itself.

Thanks a lot! This version has been the work of two months in my spare time (it's true that with confinement I had some full weekends to spare!).

I'm not using Cluster API, but the oneinfra's defined set of API's, that are reduced in purpose, to reduce the complexity of spawning new clusters. Let me know if something doesn't click, I can help!

Oh wow, hehe, I wouldn't say so. Rancher is an off the shelf solution for many layers previous and after Kubernetes is set up, their solution is "complete" taking the ecosystem into account.

This is just an "in-house" Kubernetes managed service :)

Thank you, it is indeed similar, however the idea of oneinfra was to reduce the responsibilities to create the Kubernetes API service for each cluster and that's it. The scope is very reduced in purpose. Provide something somewhat easy to set up by users and service providers, and almost trivial to integrate with, so they can start creating isolated Kubernetes clusters at will, either for internal consumption, or for external consumers.

Yes, where every managed cluster exposes an isolated Kubernetes API.

It's a managed Kubernetes service that you can run anywhere you like, you can still leverage the public cloud (even on hybrid environments), but you are not tied to a specific public cloud Kubernetes managed offering.