GSoC 2014: WebSockets in WordPress

[Atanas Penchev]

Hello!

For quite some time since I started following the development of React and
Ratchet, I have been intrigued by the idea of using WebSockets together
with WordPress. Although on Apache installations a WebSocket server would
still require running an additional process, it provides many potential
benefits for both users and developers.

By using Ratchet, I plan to write a WebSocket API which could be used for
plugin development. It should ease the creation of real-time solutions,
like new comments and posts notifications, chat systems and live updates of
the site's components (for example, automatically displaying new content to
all users as soon as it becomes available without a browser refresh).

Besides the use of WebSockets, I am also thinking of using the React server
for serving request, which could provide a significant performance boost,
as mentioned in this post:
http://marcjschmidt.de/blog/2014/02/08/php-high-performance.html

During the time working in a small company, I had to go through WordPress
theme and plugin development. Also, I had developed several applications
with Node.js/PHP + React and WebSockets and I believe it would be a great
experience combining my skills while improving such a successful project.

What are your thoughts on the idea? Any feedback would be useful. :)

[Bryan Petty]

Post by Atanas Penchev
Besides the use of WebSockets, I am also thinking of using the React server
for serving request, which could provide a significant performance boost,
http://marcjschmidt.de/blog/2014/02/08/php-high-performance.html

That article is pretty nice, and even points out some of the downsides
and technical issues involved, which are also very critical to
WordPress as well, so let me just briefly cover them to the best of my
knowledge.

1. While Symfony contains a Request/Response system that he talks
about in that article, in WordPress, it's much worse. A bunch of core
functions and plugins directly access superglobals for $_REQUEST and
$_SERVER values. As pointed out, those are entirely unreliable in the
environment of asynchronous requests.
2. Also a problem for asynchronous requests: hooks. These are bound by
global context, meaning hooks would have no idea what request/client
was being served, which DB resource to use (what if we were in a
transaction?), or what output stream to echo out to. ReactPHP was
built with MVC architectures and template engines in mind - neither of
which we use. And as far as backwards compatibility goes, there's
likely nothing we can do to handle any of those while staying
compatible with existing plugins.

So, even if we managed to work our way around blocking IO calls (PDO,
DNS, etc), this means that we still can't use async requests. It's
best to just forget about it (especially for GSoC). That doesn't mean
we can't still use WebSockets or React, it just means that we can't
use async/promise. Of course, this defeats most of the performance
gains React likes to gloat about, but it would still cut back on PHP
initialization.

Unfortunately, without async, this introduces another problem. It
means we will be performing blocking calls (which was likely going to
happen anyway with PDO). And since we'll be blocking, we won't want
one user blocking requests from another user, so we would likely want
to avoid re-using connections across sessions. We probably already
want to anyway since authorization checks also rely on request/session
identity stored in global values. This is a difficult task which I'm
not sure has a solution with a fixed server pool configuration. It's
not going to scale with 50+ concurrent admin users (including authors
writing posts) leaving heartbeat WebSockets open to individual PHP
processes on different ports.

Maybe I'm wrong about some of this, and hopefully someone else on the
list can correct me or point out other solutions I'm not aware of to
these problems. But this is all probably worth some discussion before
any students jump head-first into this for GSoC.

Regards,
Bryan Petty

[Atanas Penchev]

Bryan Petty, thank you for the valuable feedback. After what you have
pointed out, which seems valid, for me it looks like the whole purpose of
using React (and Ratchet) is lost. Since we have to use another process for
WebSockets anyway, we may as well use another language or server (for
instance Node.js).

Still, I suppose a PHP WebSocket server will still be available as an
option on cheaper hosting solutions, which are the main platform for
WordPress.

In that case, I guess the only viable option for the WebSockets project is
to write a plugin which check if it is possible to open a separate
connection and if so, to start a WebSocket server and expose an API which
could be used by other plugins. One of the other candidates has already
offered to work on that.

With kind regards,
Atanas