Non Blocking, Reactive I/O

[nehanims]

Read the reactive manifesto Look into reactive I/O for different programming languages

[nehanims]

Non-blocking reactive endpoints offer several advantages, especially in scenarios where handling a large number of concurrent requests efficiently is crucial. Here’s a breakdown of the benefits and some examples of popular libraries and frameworks:

Advantages of Non-Blocking Reactive Endpoints

1. High Concurrency Handling:

   • Reactive endpoints allow servers to handle many more concurrent connections compared to traditional blocking I/O. This is because threads are not blocked waiting for I/O operations (like reading from a database or network), allowing them to be reused for other tasks while waiting for responses.

2. Better Resource Utilization:

   • By avoiding blocking, reactive systems can make more efficient use of CPU and memory. Since threads aren’t sitting idle waiting for I/O, the system can serve more requests with the same hardware.

3. Scalability:

   • Reactive systems scale better with the number of requests, especially under high load. This is particularly beneficial in microservices architectures or cloud environments where services need to scale dynamically.

4. Improved Responsiveness:

   • Applications can remain responsive under load because they can continue to process incoming requests without being bottlenecked by slow I/O operations.

5. Fault Tolerance and Resilience:

   • Many reactive frameworks offer built-in patterns for handling failures, retries, and fallbacks, which contribute to building resilient systems.

Popular Libraries and Frameworks

1. Java/Spring Ecosystem:

   • Project Reactor: The core library in the Spring ecosystem for building reactive applications. It’s used in Spring WebFlux, the reactive counterpart to Spring MVC.
   • RxJava: A popular library for composing asynchronous and event-based programs using observable sequences. Often used in Android development and other JVM-based projects.
   • Vert.x: A polyglot event-driven application framework that supports reactive programming. It’s particularly useful for building microservices and high-throughput web applications.

2. JavaScript/Node.js:

   • Express.js with async/await: While not inherently reactive, Node.js uses a non-blocking event-driven architecture. Express.js, combined with async/await, can be used to create non-blocking APIs.
   • RxJS: A library for reactive programming using observables, extensively used in Angular applications for managing asynchronous operations.

3. Python:

   • FastAPI: A modern, fast (high-performance) web framework for building APIs with Python. It is based on standard Python-type hints and uses the async and await syntax for non-blocking code.
   • Tornado: A Python web framework and asynchronous networking library, originally developed at FriendFeed.

4. .NET:

   • ASP.NET Core: With support for asynchronous programming using async and await, ASP.NET Core can be used to create non-blocking APIs.
   • Reactive Extensions (Rx.NET): A library for composing asynchronous and event-based programs using observable sequences in .NET.

Projects That Benefit from Non-Blocking Reactive Endpoints

1. High-Throughput APIs: Services like social media platforms, real-time analytics dashboards, or any service expected to handle a large number of concurrent API requests.

2. Streaming Data Applications: Applications processing streams of data, such as video streaming services, live sports updates, or stock market tickers.

3. Microservices Architectures: Systems composed of multiple microservices, where inter-service communication needs to be efficient and resilient.

4. IoT Applications: Applications that need to handle data from numerous devices in real-time, such as smart home systems or industrial IoT solutions.

5. Event-Driven Systems: Systems that react to a series of events, such as user actions in a web application, or events from a messaging system like Kafka.

6. Cloud-Native Applications: Applications designed to scale elastically in cloud environments, where efficient resource utilization is crucial.

[nehanims]

full-stack, reactive generative AI apps -- full list of articles https://dev.to/tutorialq/building-scalable-applications-with-kafka-and-reactive-programming-5cea

[nehanims]

Official Spring reference for Kafka: https://docs.spring.io/spring-kafka/reference/kafka.html

Kafka Listener is Async compatible now

But, if looking for an alternative, use Kafka-reactor instead of spring Kafka (spring Kafka reactive support with completarle future came much after project reactor's reactive Kafka API with flux and mono so maybe it's more mature?) so be careful about which one you're using and stick with it even though I think there's some sort of mono in spring Kafka e.g. the Kafka listener can support returning a mono but it's not clear if the support is very well defined.

Here's the reference for Kafka reactor

https://www.baeldung.com/kotlin/apache-kafka https://kotlinlang.org/docs/async-programming.html https://www.baeldung.com/kotlin/coroutines-vs-rxkotlin

[nehanims]

Difference between future and reactor flux/mono: Future is actually synchronous only(Future block waits on a thread to receive the result) whereas, Mono/Flux can be both asynchronous and synchronous. CompletableFuture is the equialent async version of Future.

[nehanims]

So here's a problem to consider when dealing with handling asynchronous events in the front end. You don't want the event to disrupt the users workflow or confuse the user. So, be very careful about using reactive updates in the front end. The user should be aware that a change has happened and not just suddenly see a different UI than a second ago because of UI refresh from a non user initiated event:

• don't add reactivity to any editable component or its parent component. E.g. if you click on a list item and an editable popup screen appears, you don't want the underlying list to change while you're working with the popup. Actually even if the components aren't editable, sudden unexpected changes can be confusing
• maybe when a UI component receives an update event, show the user a little refresh button with a tool tip indicating there are updates to show so that the user is aware that there's updates but only sees changes when they take the action of updating the UI
• having to refresh the screen too often could become tedious, so an alternative is to only append to a list never update the existing UI due to a server initiated event. In particular, for your case, only add to the end of the list of suggested metrics. Make sure the existing lists items retain their original object ID etc, so that it can't possibly affect the UI. Also, use lazy loading so you're only fetching elements that are in a certain window around the viewable height of the list container component.
• another strategy in this particular case is to show the suggested metrics corresponding to recently submitted voice notes as a list attached to the recording. You're not going to be updating the old suggested metrics so have them in a list like "backlog action items" or something like that which is created anytime the screen refreshes and stays like that (OR the backlog could be for anything older than today or something like that). This would provide a consistent UI since only a few isolated pieces in the UI would be updated, and this would be a specific component in the UI component associated with the most recently submitted voice notes and more typically only the last one.

[nehanims]

Excellent talk by Netflix engineer Ray Phelps about how to to use rxjs+redux with react to handle reactive UI and the problem rxjs solves. Worth watching again and taking notes.