Running PHP fast at the edge with WebAssembly (opens in new tab)

Of course there are always exceptions. Often stale data is ok and you can ship data snapshots to the edge so that they can be served without going back to the central DB. But in many cases some basic cache policies with a CDN can be nearly as effective.

Some other providers have tried to solve the problem with replicated databases that are used for local reads.

I can't go into details yet, but Wasmer will offer a solution for this problem quite soon as well, which hopefully will be much more seamless than existing strategies.

(note: I work at Wasmer)

I've personally seen this with a game recently and my own ISP. I can ping their West Coast servers in 20-40ms while pinging their Chicago servers takes 200ms+.

This is actually one huge flaw with the current way IP is done. Because your ISP is closely tied with the last-mile of routing, you have very little control over optimizing those backend layers of routing.

This doesn't explain why you wouldn't just run a thin proxy at the edge and instead want to run a full PHP app. For that, my guess is this makes sense when you don't want to run a full server all the time or if you want it to be rapidly scalable.

You do caching so you don't always have to go back to the DB is the main thing. The other interesting capability is light scripting at the edge. Think "this page is cached but I'm going to add in a custom username".

There's some more exotic stuff around sharded database locality. But I'll skip over that because distributed mutable state is hard and its not my specialty.

Connection warming and shorter tls negotiation round trip times are also a thing but probably less important compared to the database thing you are mentioning.

But mostly this architecture makes sense if you can do some caching or if you're doing more data/log collection stuff.

For prior work see ESI (edge side includes). Assembling stuff at the edge does have some benefits but it has been hard to create a good interface for that.

Unless you host the database in the same network as your edge provider, appliation <-> database is where the bottleneck is.

For example, a form builder like typeform could cache form definitions on edge and render them close to users. Submissions would require db communication but the entire experience could be better.

Otherwise it is just not worth it.

BTW, I don’t even think PHP running slower in wasm would be that important. These things generally depend on IO performance rather than runtime if you are not doing a lot of calculations on the edge. WASM is also pretty fast these days so..

I agree with you, and it's not faster. With the risk of sounding old (get off my lawn): I assure you the megabytes of unneeded Javascript they're downloading to the client are ten times slower to execute than the milliseconds they may be saving on the wire.

Client talks to closest system, TLS gets terminated as soon as possible.

Certain things can be cached on edge which normally can't be cached just through basic http (like as soon as you are logged in).

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.

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.

But you are completely right pointing out that there's still some room to improve, specially when compared to running PHP natively.

Right now there's some price to pay for the isolation and sandboxing, but we are working hard to reduce the gap to zero. Stay tuned for more updates on this front!

If you’re on PHP and need more speed in the language itself, basically every other scripting language (yes, including Node) is off the table immediately. Lateral move at best.

(All that to say, yeah, I entirely expected that the headline would lead to an article about making PHP slower)

"What if our code ran in tens of thousands of different environments that we have no control over, rather than a single server environment we control!"

Various interpreters might or might not have a good capability/permissioning model (Java's is capable but complex and not supported by many applications, for example); even if they do, there might be exploitable bugs in the interpreter itself.

Also, not everything requires a database.

1. latency

2. intermittent access

3. distributed "meaningful" data preparation/filters

One may consider routers with squid proxies, VoIP trunks, and p2p cache are essentially similar "edge" technologies.

There are additional use-cases, but we don't want to educate the lamers stealing resumes off jobs sites... having no clue what they are talking about.

Have a nice day, =)