I'm still trying to understand what this does and what's the use case. Is the "edge" a server? The browser? Why should I compile WordPress or Laravel to wasm?
In this context the edge is a fancy word to say "serverless". It just means that your PHP interpreter will be started on-demand on a node closer to your customer's request.
So if your website receives no requests, it costs you nothing. And requests have less latency for the user.
That's the theory anyway, in my experience reality is a lot more nuanced because the serverless node still has to reach a database and so on.
This seems like a misunderstanding, WebAssembly has nothing to do with PHP’s internal performance mechanisms. WASM is a compilation target, this means you can take code which needs to be compiled (like PHP’s core binary), and compile it to be run in a browser.
PHP in WASM means developers can run actual, real, native PHP code in the user’s browser, without the user needing to have PHP installed locally, or nginx, etc…
You could do that, but the post here is in fact about running PHP on a server on top of a Wasm runtime.
“At the edge” basically means “close to the user”, with the details left as an exercise to whoever is selling you their “edge.” In this case, it’s a Wasm runtime company.
Yes, though I'd like to point out that "scale to zero" is a loose definition to mean anything that can be transparently scaled to 0 whenever an app/service is idle, and then wake up when traffic to the service arrives once again.
The problem in practice with Cloud Run (and similar products from other providers) is that it can take seconds or minutes for the platform to detect idleness, during which you're still paying, and then seconds to wake up -- during which users/clients have to wait for a response or possibly leave the service/site.
For my taste, real scale to 0 would be: detection and scale to 0 within < 1 second of a idleness, and wakeup within an RTT, such that the mechanism is transparent to end users.
As a shameless plug, this is what we do at kraft.cloud (based on years or research, LF OSS work, unikernels, a custom controller and overall non-negligible engineering effort).
The “edge” in this case is the browser (from a pure WASM standpoint, though I see these guys also offer a hosted serverless version too).
For most general-purpose applications, there’s no point to WASM. But some apps may run specific functions which take a long time (e.g. bulk/batch processing), and being able to execute those tasks securely on the client side provides immediate feedback and better UX.
That’s just one use case. Another is that WASM makes PHP portable, in the sense it can run in any web browser without the need for a back-end server. Lots of potential opportunities for distributing software which runs completely locally.
Thank you for explaining. As a Web dev, who's using PHP since version 4, I'm still very confused why someone would consider running a CMS like WordPress on the client side, or at the "edge". I guess the good thing here is that someone spends (a lot of) energy in giving PHP new ways to get used by developers.
The edge within this context means running a server close, in terms of Internet latency, to users. For example, if a user if sending a request from Germany, then the response should come from a server running in say Frankfurt, not the US. There are now many providers that allow devels to deploy services at many different locations at once, and to ensure that client requests are routed to the closest available location. An understandable source of confusion is that wasm comes from the browser world, but it's also possible to run it as standalone (no browser) server code.
Also not to be confused with the term edge within the context of IoT/embedded, where the edge is devices running at the very edge of the Internet, e.g., factory floors, trucks, etc.
The browser is not the "edge". The browser is the browser. Running WordPress in the browser makes exactly zero sense. Only exception if you are running a test instance.
