Python on the Edge: Fast, Sandboxed, and Powered by Webassembly

Forgot to put it on the article, but the latest Python requires the Wasmer rc.5 to run! (the final release will be coming very soon)

    curl https://get.wasmer.io -sSfL | sh -s "v6.1.0-rc.5"
    wasmer run python/python

error: Spawn failed

╰─▶ 1: compile error: Validate("exceptions proposal not enabled (at offset 0x191a)")

```

What’s the use case? Is it the sandboxing? Is it easier than running Python in a container?

Normally, if you want to run your apps serverlessly you'll need to adapt your source code to it (both AWS Lambda and Cloudflare Workders require creating a custom HTTP handler).

In our case, you can run your normal server (lets say uvicorn) without any code changes required from our side.

Of course, you can already do this in Docker-enabled workloads: Google Cloud or Fly.io, for example. But that means that your apps will have long cold-start times at a way higher cost (no serverless).

Hope this makes things clear!

My preferred definition of serverless is scale-to-zero - where if your app isn't getting any traffic you pay nothing (as opposed to paying a constant fee for having your own server running that's not actually doing any work), then you pay more as the traffic scales up.

Frustratingly there are some "serverless" offerings out there which DO charge you even for no traffic - "Amazon Aurora Serverless v1" did that, I believe they fixed it in v2.

It seems like a horrible way to build a system with any significant level of complexity, but idk maybe it makes sense for very rarely used and light routes?

See https://github.com/ninia/jep

Part of why WebAssembly was successful is that it's a way of generating javascript runtime IR instead of a completely new language + standard library - browsers can swap out their JavaScript frontend for a WASM one and reuse all the work they've done, reusing most of their native code generator, debugger, caches, etc. The primitives WASM's MVP exposes are mostly stuff browsers already knew how to do (though over time, it accumulated new features that don't have a comparison point in JS.)

And then WASM itself has basically no standard library, which means you don't have to implement a bunch of new library code to support it, just a relatively small set of JS APIs used to interact with it.

That being said, I'm also 100% behind the effort to standardize WASM as the cross-platform compilation target of choice.

I remember when I was in 6th grade wanting to make some minecraft mods but didn't want to learn java for it and wanted something like python.

I also remember a video that did something like that but it was highly limited or smth iirc.

Could this be used to create a minecraft plugin in python?

Edit: Damn, there is this pyspigot thing which seems really fascinating..

https://pyspigot-docs.magicmq.dev/#getting-started

Tbh, nowadays I would prefer writing minecraft mods in kotlin but the pyspigot code is also definitely really interesting!

If you use wasm's native GC your objects are managed by the WASM runtime (in browsers, a JS runtime).

For things like goroutines you would emulate them using wasm primitives like exception handling, unless you're running in a host that provides syscalls you can use to do stuff like stack switching natively. (IIRC stack switching is proposed but not yet a part of any production WASM runtime - see https://webassembly.org/features/)

Based on what I read in a quick search, what Go does is generate each goroutine as a switch statement based on a state variable, so that you can 'resume' a goroutine by calling the switch with the appropriate state variable to resume its execution at the right point.

In a browser environment there are theoretically ways you could piggyback off of the async support in the native ecosystem. But CPython is written to certain systems, so you're talking about CPython patches.

BUT the kind of beautiful thing is you can show up with your own asyncio event loop! So for example Pyodide just ships its own asyncio event loop[1]. This is possible thanks to Python's async infra just being built off of its generator concepts. async/await is, in itself, not something that "demands" I/O, just asyncio is.

[0]: https://docs.python.org/3.13/library/asyncio.html [1]: https://pyodide.org/en/stable/project/release-notes/v0.17.0....

In fact, we want to even run it on browsers.

We are small team, so we have to pick our battles very carefully, but we would welcome any patch to make it work (if it doesn't work already!).

Philosophically speaking I believe we should not require a special version of pip to install packages, nor a "lite" version of Jupyter to run in WebAssembly.

We should be able to run Jupyter fully within the Wasmer ecosystem without requiring any changes on the package (to run either in the browser or the server).

Wasmer's approach hints at faster cold starts and better overall performance; the benchmarking against pyodide is a bit unclear, and it's unclear to me whether that would make or break viability for a use case like this.

But one thing this does make possible is if your arbitrary script is actually a persistent server, you can deploy that to edge servers, and interact with your arbitrary scripts over the network in a safe and sandboxed way!

Please no :sob:

And you can also use Websockets with Cloudflare workers: https://developers.cloudflare.com/workers/runtime-apis/webso...

However it's worth point that due to the concurrency model of AWS Lambda (1 client request / ws message = 1 lambda invocation / one process only ever handles one request at a time before it can handle the next one), you would end up spawning much more AWS Lambda instances than you would with Cloudflare workers or Wasmer Edge.

There are cost implications obviously, but AWS lambda works this way also to make concurrency and scaling "simpler" by providing an easier mental model. Though much more expensive in theory

If you are curious on compiling Python to WebAssembly please check py2wasm: https://wasmer.io/posts/py2wasm-a-python-to-wasm-compiler