Wasmer Edge: WebAssembly on the Edge
wasmer.io
wasmer.io
If you are interested in knowing how it works I recommend reading the docs [1], we have invested quite some time in them. Please let us know if more info might be useful and we will work on updating them.
> What can you host with it
Right now any static sites and Rust applications (including webservers and other TCP/UDP applications). Support for Node.js and Python is coming very soon!
> How does the pricing compare (free tier?)?
During the private alpha, Wasmer Edge will be completely free for its users.
Once the beta becomes public and available to everyone, pricing is expected to be comparable to Cloudflare Workers. We have also drafted the pricing on the product page [2]
I imagine that admin panel has those answers, but well, I'm really not doing a deployment to see it. (I'm not even creating an account.)
You're referring to this? https://docs.wasmer.io/edge/quickstart/http-server Personally, I found it pretty instructive.
The current regions are us-east, us-west, and eu-central: https://docs.wasmer.io/edge/architecture
> but there's no mention of database or filesystem.
The docs do point out that stateful workloads are in their plans.
I'm Syrus, from Wasmer. We have created Wasmer Edge as a powerful alternative to the Clouds. An alternative that allows reusing the codebases that worked in the Cloud without rewriting them to custom SDKs (such as Amazon Lambda, or Cloudflare Workers), and running them at CDN-like prices.
With Wasmer Edge you can use a normal http-server in any language or even write a full DNS server based on it. We are incredibly excited of the paths that will open ahead.
For those interested, here's the document showcasing how everything is architected:
https://docs.wasmer.io/edge/architecture
Feel free ask any questions you may have here, myself and the team will be incredibly happy to answer them!
That said,
>Join the waitlist to try Wasmer Edge today and experience the difference for yourself.
... this was very anticlimactic, it made me look away, honestly.
Could you just let us all in?
I guess we really internalized YC's motto: we rather have one person having a great experience and loving us, than 10 liking us with an ok experience than 100 using us with a poor experience ...and the waitlist helps on that quest.
Although it seems there's a good chance you'll love the product. Feel free to message me to syrus@wasmer.io and we'll be in touch soon!
Bytecode Alliance moving slow and steady. Does wasm have sockets? Maybe?
Don't trust Wasmer and don't like their big JVM-style moves, but I guess it's nice to see wasm happening!
All I need is wazero and wasmedge and wasmtime (and toy programs that don't do much).
I believe you will end loving it (btw, I share your love with Wazero... their team is awesome! <3)
Now when I read about the architecture and the locations it just seems like ordinary cloud hosting, albeit serverless, to me. I can't make much sense of phrases like "The core design of what makes up the Wasmer Edge code base is a distributed monolith" either.
So thanks in advance for any help :)
> You're a master at communicating technical concepts to developers by being concise, removing fluff, and speaking plainly without any marketing speak. Please explain what the following means...
Sure. Here is my explanation of the quote you provided:
1. Distributed monolith: A distributed monolith is a software architecture that combines the benefits of both monolithic and microservices architectures. Like a monolith, all of the code for a distributed monolith is contained in a single binary. However, like a microservices architecture, the code is divided into independent libraries that can be deployed and scaled independently.
2. Separation of concerns: Separation of concerns is a software design principle that breaks down a software system into smaller parts, each of which is responsible for a single, well-defined task. This makes the system easier to understand, maintain, and evolve.
3. Rust libraries: Rust is a programming language that is designed for speed, safety, and reliability. Rust libraries are compiled into machine code at compile time, which makes them faster and more efficient than interpreted languages like Python or JavaScript.
4. Scalability: Scalability is the ability of a software system to handle increased demand without sacrificing performance. Distributed monoliths can be scaled out by adding more nodes to the system. This makes them a good choice for applications that need to be able to handle a large number of users or requests.
a distributed monolith is an antipattern that's common to badly executed microservices -- it's essentially an epithet, in no sense a design goal
what's being described here is an _elegant_ monolith, which is entirely different, and definitely does not provide the property that independent libraries can be deployed and scaled independently
It does, and the product page (https://wasmer.io/products/edge) makes it a lot clearer than the linked announcement that Wasmer Edge is basically "Cloudflare Workers for Wasm".
The chart at the bottom of the page¹ shows what Wasmer thinks Wasmer Edge completes with — Cloudflare Workers, Amazon Lambda, Fly.io, and "Cloud" (whatever that is). The most significant differentiator seems to be that Wasmer Edge runs on browsers and phones in addition to servers in the cloud, which makes it "edgier" than the alternatives.
¹ Note that it calls the service "Wasmer Deploy" instead of "Wasner Edge", which I assume is a mistake.
> US West Coast
> US East Coast
> Europe Central
Can someone please fill me in on how this is edge, these are the 3 regions every cloud provider has
In traditional Cloud Computing the customer must "select" where it runs (i.e. pick a data centre or region) - for instance, when you go in the Azure portal for many services like AKS you must select where it is hosted. In Edge computing you don't need to do this as it automatically serves the request at the closest "pop" (point of presence), this is also how Wasmer Edge works.
Wasmer Edge are in an alpha release phase thus the edge network is kept purposely limited in this early pilot to take a careful approach to its expansion.
Wasmer also have plans to build a hybrid environment between the browser itself and the edge network which will unlock some really exciting use cases thanks to WASIX.
Ignore the troll reply... he is paid (or just sells himself for free) by the competition to discredit... just downvote him.
But Wasmer Edge does not run close to most customers and does not run on their browser.
> Wasmer Edge are in an alpha release phase thus the edge network is kept purposely limited in this early pilot to take a careful approach to its expansion.
I think Edge is something where a limited pilot makes no sense. It would be like selling a database that is only available in the morning. If having very low latency is a key concern of mine then a service close to half my users is much less than half as useful as a service close to most of my users.
> Wasmer also have plans to build a hybrid environment between the browser itself and the edge network which will unlock some really exciting use cases thanks to WASIX.
If this isn't running in the browser than it has to be running in a server. By between the browser and the edge network I'm guessing you mean you'll purchase a large number of servers even closer to users than existing edge networks. That's hard, and your product so far doesn't suggest expertise in that area. I don't see how wasm will significantly help you get more servers closer to users than existing companies in this space.
> Ignore the troll reply... he is paid (or just sells himself for free) by the competition to discredit...
Based on your parenthesis I'm assuming that you don't actually know anything, you just assumed that because he's critical he's a troll?
> just downvote him.
Why don't you respond to their argument
I did
> But Wasmer Edge does not run close to most customers and does not run on their browser.
It does run in the browser, that is what https://wasmer.sh uses to launch things published via the `wasmer publish` command. There are more plans to integrate these closer together into a hybrid system in the future with converged networking and transparent offloading work to servers, needs more work but its for sure possible with this foundation.
> I think Edge is something where a limited pilot makes no sense.
One does not just hit a button and servers appear everywhere in the world at once for free, all CDN's do the same thing, they run in racks of servwrs and expand their POP's based off real data and not just guess work. For instance, apparently Japan has a massive interest in WASIX, so perhaps the next POP should go there. Its also worth mentioning that if Wasmer Edge had been built on top of someone elses Edge (as others have done) then they would never be able to offer the cheap pricing.
> I think Edge is something where a limited pilot makes no sense.
It is a good point you make here about perception versus alpha relaity but with the architecture of the design and the huge amount of interest coming from the community the locations will expand quickly so it will be a growing pain of history fairly quickly.
> I don't see how wasm will significantly help you get more servers closer to users than existing companies in this space
No other company I am aware of are trying to build a distributed computer that lets developers write a program that runs in a hybrid setup of running in the literal browser of the user and connected to high performance compute in data centres. Honestly this is the bit that really excites me, imagine a program that runs in the browser but has real threads that also run in a data center. Exciting times.
- push code out to multiple regions
- direct traffic to the best region
- scale up and down and balance reducing cold starts and serving with nearby servers
They can't build this with only 3 regions, so it's marketing fluff or if you're feeling really charitable in its early stages.
If you use tokio in this, is it effectively a single-threaded tokio runtime, or do you have a way to take advantage of multiple cores?
That's actually how we have implemented static sites.
For each site a a WebAssembly instance is spawned that runs a tokio static-web-server [2], which is multi-threaded and concurrently handles requests.
That way the Edge serves static sites in the exact same way as you can run them locally (with `wasmer run wasmer/docs`, for example).
Right now we are starting with Rust (with full networking with tokio) and static sites.
Node.js (allowing Next.js to be fully runnable) and Python (allowing Django and Flask) support will be coming soon!
BTW, SWC is already powered by Wasmer!
I've heard about efforts to compile SpiderMonkey to WASM to run JS, but never V8 and the entirety of Node.js. That would be super exciting if that's what you're looking to accomplish. Would love to follow along and contribute if this is part of an open source effort!
Curious if you think cold starts could be a problem with this approach? Share-nothing architecture sounds great until you realize you have to load the entirety of V8 and Node.js on every request, but maybe you've figured out some way to work around that?
Also, how do you think the lack of JIT could affect real-world JS runtime performance? Or is there a solution for that too?
TLDR: support for WASIX [1] enabled builds that can start a web server (Rust with axum works well, Python and PHP are coming soon), and WCGI, with which you can use all languages that currently have WASI support , by using the standard CGI interface.
We'll also add support for standard WASI with pre-opened sockets, which will add support for a bunch of additional ecosystems (like dotnet / C#), but haven't gotten around to that yet.
If you are asking more about how code is managed and executed: stateless, spawned on demand is the default. Proxy mode will re-use instances for multiple requests. Stateful/persistent instances with persistent volumes are on the horizon.
In addition to that, I added some constants to "..sdk\gotip\src\syscall\syscall_wasip1.go" by hand that were throwing errors about being undefined, just by copying the values from the default unix syscall package. They were about OS files and I figured I shouldn't need them for the WASI module.
But the documentation is lacking and sometimes out of date as you perhaps found out. I'm currently stuck at having the gRPC server object in Go, and the service implementation on the WASM side, and in need of a way to register that service on the server. This means for server.RegisterService(pb ServiceDesc, &server{}) I would need to smuggle out pb and a pointer to the implementation, or for server.RegisterService(pb ServiceDesc, &server{}) smuggle in a grpc.Server pointer...
It avoids all the GPRC mess You can instead use Proto and let NATS be be Transport.
Persistence is on the roadmap though.