Push system in 5.5

For a better understanding I would like to explain here how the live update works technically.

A typical call of a web page is called "polling": The browser sends an explicit request to the server and receives the response. PHP was developed exactly for such use cases and can show its strengths. The disadvantage, however, is that the browser must constantly send requests to the server to be informed about new things, which causes a lot of load and is therefore rather unsuitable for an automated retrieval of information (such as in a chat). The counterpart to this is called "push", where a stable connection is established between the browser and the server, where the browser waits "indefinitely" for data from the server. So as soon as there is something new on the server, it can immediately inform the browser about it. However, PHP is unsuitable for exactly such tasks, because each request has a time limit and blocks important resources on the server.

We support a large number of customers in the WoltLab Cloud and were faced with the question of how we could efficiently implement a push service during the planning phase. In the case of a single customer, for example, it would have been conceivable to fall back on a node.js-based service; this can process a high number of parallel connections and the memory requirements are also acceptable at around 100 MB. However, this approach does not scale linearly: what works on a small scale turns out to be a bottleneck at the dimensions we are working in.

For the WoltLab Cloud, we needed a system that could handle high five-figure parallel connections while being efficient with memory. To pick up node.js again at this point: With, for example, 400 instances, the memory requirements would already add up to ~40 GB, and that's just in idle mode. So there was no question for us that we need a solution that is shared between different customers and at the same time ensures isolation of the data. To this end, we developed a push service that was ideally suited to our scalability requirements. For the implementation we decided to use the programming language "Rust", which allows us to achieve performance and efficiency comparable to C/C++.

As mentioned elsewhere, we rely on a comprehensive and strict security concept for the WoltLab Cloud. Our internal network is built according to the "zero trust" principle, the systems basically do not trust each other and only allow precisely specified connections. Instead of user names and passwords, we use certificates for internal authentication. When connecting from PHP to MySQL, PHP identifies itself to the database with a certificate and vice versa. In this way, both systems ensure that they are actually communicating with the correct system. We also apply this procedure to other services and last but not least the communication of PHP with the push service or the connection from the load balancers to the push service is based on the concept of authentication with certificates ("Mutual TLS").

Due to our architecture, we were able to avoid a large number of obstacles that become a problem with a typical web server/PHP stack. For example, an nginx as reverse proxy for the push server, which does not implement TLS itself, is de facto incompatible in the default configuration - but this is not a problem for us, since we rely on HAProxy as reverse proxy from the beginning. The integration into our existing architecture was obvious, with HTTP/2 the connection setup to the push service becomes practically free, we avoid redundancies in the encrypted connections and we could also elegantly bypass CORS. A decisive advantage was the strict focus on Linux/UNIX, so that we did not have to deal with the manifold peculiarities of Windows servers. And Windows servers are much more common in (v-)servers than one would generally assume, typically because other server services are run in addition to the web server.

This solution is far too inflexible for use in a self-hosting environment; for that, a completely different technical approach would have had to be chosen, which would then again be significantly less powerful and thus rather unusable for us in the cloud. Ultimately, we would probably have had to develop two separate versions of the solution, with the corresponding additional development effort.

In addition to the development effort, experience has shown that the support effort for such a product is not insignificant. Own servers in the self-hosting environment are usually unmanaged and the questions about problems with the server configuration usually end up with us. We have made similar experiences with the Elasticsearch plugin, for example. Due to the development effort and especially the support effort, such a solution for the self-hosting environment would only be conceivable as a paid plugin, probably in the region of the Elasticsearch plugin in terms of price.

And here comes the problem: The target group for such a plugin would be rather limited. According to our estimates, only 10-20% of self-hosting customers even have the necessary infrastructure to run such a plugin. And of these 10-20%, only a smaller part would even consider buying it. On the one hand, of course, because of the costs and, on the other hand, because there are already similar solutions from third-party providers, e.g. NodePush. In the end, we might be looking at a mid-double-digit number of sales here, and hopefully I don't have to explain that this doesn't make sense for us from an economic point of view.

For the cloud, we were able to do it relatively inexpensively because we were able to leverage existing structures. At the same time, the support effort is practically zero, because we take care of the administration ourselves. Previously, this was also a clear disadvantage for cloud customers, as they could not access existing solutions such as NodePush. In addition, our cloud tariffs are based, among other things, on the page views caused, which is why plugins that work with polling and thus generate many page views (e.g. chat) are problematic. With the live update, we would like to provide an alternative for polling in these plugins for the cloud in the medium term.

If the demand situation should change in the future, for example because the use of our own servers should increase significantly, I can also imagine that we will still offer a variant of the live update for the self-hosting environment. To be honest, I don't see that happening at the moment.