ANALYSIS OF THE PRINCIPLES OF REACTIVE PROGRAMMING BASED ON THE JAVA LANGUAGE AND THE SPRING BOOT FRAMEWORK IN COMPARISON WITH THE MAIN APPROACHES TO APPLICATION DEVELOPMENT
DOI:
https://doi.org/10.31891/2219-9365-2024-78-24Keywords:
reactive programming, application, BE, thread, subscribeAbstract
This topic is relevant because modern systems need to handle large volumes of data, load balancing, easy expansion and small amounts of resources on the cloud. Load balancing requires an increase in the resources used at the hardware level, but this is only a temporary solution unless changes are made to improve it at the code level. The need today is not just to get an even result, but to get it quickly with the least amount of resources used. The biggest problem with the performance of BE applications is the inefficient use of threads at the server level. During the execution of one thread, there are moments when it is idle waiting for a response from various auxiliary resources or the database. This time can be effectively used for lossless information processing to perform the main functionality of the stream.
Reactive programming is built around two structures, Mono<T>[1] and Flux<T>. When Mono<T> is executed, all depicted events occur in one thread, the operator processes the object and returns it to the Subscriber object. Returns an error on error. The principle of operation of Flux<T> is identical to the operation of Mono<T>, the only difference is the number of objects that are processed. Both constructs implement methods Publisher and CorePublisher, which inherits from Publisher. These abstractions contain only one method subscribe(CoreSubscriber<? super T> subscriber). This method is called only when calling a method that returns a Mono<T> or Flux<T> object. From which we can conclude that using a reactive approach to writing logic, we subscribe to the result of the execution of the method. In this way, it is possible to track when a method is waiting for a result and requires a thread to continue executing logic. This approach is implemented according to the Observer pattern principle. Reactive programming also uses a pattern like the Interator to get a thread to execute the next method or functionality that doesn't necessarily belong to the user thread. In this way, the framework allows not only to provide a thread to execute when the wait is over and we have a result, but also to free up that thread to execute other methods that do not require waiting.
Reactive programming is a design approach that uses asynchronous programming logic to execute code. Reactive applications that are non-blocking by design and allow the application to scale with a small fixed number of threads and lower memory requirements, while making the best use of available computing power. This sets it apart from the user thread blocking approach and the asynchronous approach to data processing, which either block the thread without effectively using it.