I think we need to compare the upsides/downsides to this, for example, memory-wise, which can handle more connections concurrently on the same amount of ram, from what I understand, this is where NodeJS excels (using less ram for more connections), (I may be wrong)

Here's an implementation of a web sockets server in PHP: https://github.com/hach-que/Omni/blob/master/src/pipe/WebSocketEndpoint.php

There's also a WebSocket framework called Ratchet, which is built upon React. I used it for some small apps in the past and it worked quite well for me.

This task is about removing an external dependency (for security and simplicity), not really swapping one for another.

Okay, that sounds reasonable.

I'd really like to see this happen. So far I haven't used Aphlict simply because I don't want to manage the extra dependency.

This is very unlikely to happen.

I selected NodeJS for scalability, effectively as the only selection concern.

I believe the maintenance burden this dependency represents is very small, based on my experience administrating this install and the Phacility cluster. Because I have operational responsibilities in the cluster I am strongly motivated to reduce the administrative cost of Phabricator, and removing the Node dependency isn't even on my radar. (It has basically run untouched since we launched, except for one reboot to swap an expired SSL certificate.)

I also think this dependency is less important to reduce setup costs on because it's optional and only enhances Phabricator. Installs can get set up without it, and pursue it later. You can configure it against an active install without any real disruption or risk.

I would be compelled to consider revisions to this approach if I were given evidence that:

1. PHP can scale about as well as Node in this role (as a server handling many concurrent connections); or
2. managing Node is unreasonably burdensome, and the burdens are of a nature which we can only really alleviate by dropping the Node dependency.

My belief is that PHP can not scale meaningfully in this role and is at least 2-3 orders of magnitude behind Node, and possibly so far behind Node that it is not suitable for anything but a toy server. Even if PHP can handle this task reasonably well for midsized installs on a single host, I don't want two servers, and I'd obviously rather have the one that works at scale. But perhaps I have bought into the hype too much and Node and PHP are approximately comparable here. I'd consider a PHP alternative if it is no more than 4x worse than Node in terms of handling large volumes of connections and traffic.

From experience, I believe Node is very easy to manage as a dependency. I have no direct evidence to the contrary.

I don't want to shipping two servers (an "easy" PHP server and a "scalable" Node server), particularly given that I believe Node is also easy. Getting notifications running isn't, at least currently, important enough to justify the costs of doing this.

I don't want to swap Node for another different external dependency unless that dependency is dramatically better on some dimension and no worse on any major dimension. I believe no such alternative exists (which is why I selected Node).

On ReactPHP specifically:

Here's something-like-a-benchmark I found suggesting that ReactPHP is much slower than Node, presumably even with the React extension installed (so this would swap a Node dependency for a PHP extension dependency -- I believe the PHP extension likely represents a greater burden for administrators):

https://gist.github.com/nkt/e49289321c744155484c

The most important metric for Aphlict is probably "maximum active simultaneous connections". It's possible that the gap here is less severe than HTTP-like open-request-close I/O thoroughput rates.

Note that ReactPHP's authors do not consider ReactPHP to be an alternative to NodeJS ,at least as of last year:

http://www.slideshare.net/vanphp/react-php-the-node-js-challenger

(See slides 33-34: "Is React PHP a NodeJS Challenger? NO".)

React is also enormous, requires Composer, and requires a newer version of PHP than the minimum we support.

If you want to move this forward:

• provide evidence that a small, pure PHP server can scale about as well at this task as Node; and/or
• provide evidence that Node is unreasonably burdensome to set up or manage, in ways that we can't fix without swapping it for something else.

To clarify: I certainly don't this dependency to be simply swapped for another dependency. Also having 2 server implementations isn't desirable either. I can't judge whether a PHP implementation can challenge the NodeJS implementation because I'm lacking the experience in PHP.