4 ms·

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 custome

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.

pjmlp 2y ago
PHP nowadays already has a JIT compiler and its own bytecode, no need for WebAssembly.
- jw1224 2y ago
  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…
  - pjmlp 2y ago
    Because I always wanted to run PHP in the browser.
  - pavlov 2y ago
    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.
aeyes 2y ago
This was solved 10 years ago with services like AppEngine in GCP and similar products in major cloud platforms, they all scale to zero.
- makeitdouble 2y ago
  In GCP land I'd assume Cloud Run is a closer service. But yes, for full blown applications udually talking to a cache and a DB there are way more efficient and performant solutions already.
- fhuici 2y ago
  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).

pjmlp 2y ago

PHP nowadays already has a JIT compiler and its own bytecode, no need for WebAssembly.

jw1224 2y ago
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…
- pjmlp 2y ago
  Because I always wanted to run PHP in the browser.
- pavlov 2y ago
  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.

aeyes 2y ago

This was solved 10 years ago with services like AppEngine in GCP and similar products in major cloud platforms, they all scale to zero.

makeitdouble 2y ago
In GCP land I'd assume Cloud Run is a closer service. But yes, for full blown applications udually talking to a cache and a DB there are way more efficient and performant solutions already.
fhuici 2y ago
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).