Why Reactive Programming is the Evolution of Web Development - PHP Nuclear Reactor package blog

Introduction

Application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data.

Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today's demands are simply not met by yesterday’s software architectures.

Traditional applications

Each request is using 2 running processes, one for each instance of HTTP server and database server. The PHP framework you use might also generate its own additional process.

The HTTP server instance is generating a request object, which is mostly overloaded for later usage.

The database instance is blocking the response until it has finished its task.

The database response is being buffered by the PHP process in order to generate the DTO (data transfer object).

The PHP process is using the DTO to generate a JSON response for the HTTP server instance.

The entire process starting with the HTTP request until serving the response back to the client, is running in the same thread. This uses the CPU's default behavior, which leads to an unbalanced usage of CPU cores.

Reactive Applications

We believe that all necessary aspects are already recognized individually: we want systems that are responsive, resilient, elastic and message driven. We call these Reactive Systems.

There is no need for a HTTP server. The application is using one single process. PHP and the database (SQLite) are running inside this process.

There is no need for an overloaded HTTP request object. The required data is mostly limited to request method, path and payload.

The response can be sent immediately to the client, while the data is being processed in the background and all necessary steps are being handled in an asynchronous manner, using events.

The database is not blocking the response, as its task is being handled asynchronously.

The entire process is happening within one persistent TCP socket, enabling the response to be streamed to the client.

The process is managing its tasks with several threads, balancing the usage of all CPU cores.

Example Implementation

As an implementation example we used lightweight components which we packed in Docker containers. AlpineOS and Ubuntu already come as Docker images ready to be used.

ReactPHP is responsible for establishing the TCP socket, transferring the raw HTTP request and sending the HTTP response back.

PIMF micro framework is responsible for managing the HTTP resources using the HTTP request methods, validating the data and handling the persistence interaction.

You can find the source code here at PHP Classes or GitHub. Feel free to fork it and experiment yourself!

Conclusion

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant to failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

You may also want to look at these additional resources:

The Reactive Manifesto

What is Reactive Programming?

ReactPHP

PIMF

Docker

This is the result of an Exploration Day exercise by Gjero Krsteski and Ralph Bach.

If you liked this article, please use the share buttons above to share with other developers. If you have questions about reactive programming, post a comment here.