SPA
Any service that gets incoming requests has to handle them and, most often, return some kind of response. Such a service can be either a service that handles tasks in a database or a service that handles requests over a network.
According to the Internet live stats, there are about 2 billion web services so far and the number of them is growing every minute. So, the number of network requests and data that should be handled, are also rapidly increasing.
Each method of network request handling has its own positive and negative sides. Therefore, the performance, speed, and operability of your application depend on the choice of approach for handling such requests.
A lot of articles consider how to handle synchronous and asynchronous network requests only partially. That's why we would like to describe the most widespread approaches to this process.
Synchronous approaches:
Probably the simplest synchronous approach to handling network requests is "Sequential handling of requests". But the lack of parallelism in request handling creates a natural queue, which makes scaling impossible. As a result, using this approach a large number of data can't be handled in a timely manner.
With a "Process for a request" architecture, an application consists of main and work processes. The main process handles incoming requests and creates a work process for each new request. In this case, scaling is the simplest, but the process consumes a lot of resources, and the absence (by default) of shared memory does not allow to have access to shared data.
At the same time, the work processes are independent of each other, and errors in one process do not affect the work of other work processes. Access rights are managed by standard OS mechanisms, and for changing the request handling algorithm the only thing you have to do is to change the script. Probably the best DBMS to handle such requests is PostgreSQL, which will make it possible to effectively use multi-core CPUs.
"Thread for a request" is also simple to implement and resembles the previous approach, except using of threads. In this case, it is possible to have shared memory and effectively use multi-core CPUs. But unfortunately, this approach is more resource intensive.
"Processes/threads pool" is a mixed approach that is difficult to implement and is quite expensive at cost. The main thread accepts incoming requests and builds them in a queue, which is handled by work processes. In this way, scaling is performed, but it is limited in conjunction with the resources used. At the same time, resources are more spent on creating a pool, which reduces costs while creating separated threads or processes and effectively uses multi-core CPUs.
Asynchronous approaches:
Asynchronous handling of all requests is typical for event-oriented handling - "Reactor pattern". Such handling consists of multiple calls followed by handlers. In a single-threaded application, only one handler is executed, while in an application that uses the "Reactor pattern" approach, handlers are pseudo-parallel.
This approach allows you to scale efficiently no-CPU-intensive requests and the number of connections, which will significantly increase application performance. "Reactor pattern" is quite difficult to implement and the occurrence of errors will lead to complete blocking of the service.
In the approach "Half sync/half async", a simplified (green) control thread is used. There are other threads in the application controlled at the OS level, but green threads are managed by the application execution system. In this case, the performance of the asynchronous approach is combined with the simplicity of programming the synchronous code.
With proper implementation of the approach, requests and the number of simultaneous connections could be well scaled. The code with the approach is easier to develop than code with other asynchronous approaches. However, errors that occurred and the handling time of requests can block the entire process, which is especially bad for real-time systems.
"Pipelining" is the handling process with a chain of several OS threads. Each thread at each moment of time performs a set of operations to handle the request.
This approach is well scaled, but unfortunately, it is not suitable for some types of network requests. Moreover, this approach is quite difficult to implement and test.
This article describes only the most frequently used approaches for network request handling and you could hear about other ones. However, more pros and cons for each method can be found in a specific situations and in specific application.
