I was researching the Java Flux API when I noticed from some tutorials that you can only subscribe to one publisher. Yet, I see a use-case where having multiple publishers to a single subscribe is useful: some sort of a data/message bus.
The only solution I found is encapsulating an array of subscribers and 1 publisher inside the bus.
My question is, which is the correct approach from a reactive point of view to this problem?
I'm interested in solving this by implementing my own Publishers/Subscribers etc. (using the Java 9 java.util.concurrent.Flow API) This project is for learning purpouses, not for production.
You can use Spring Reactor, an implementation of Java Publishers API. It has operators like concat(), merge() etc. to combine the Streams for a given Subscriber.
https://projectreactor.io/docs/core/release/api/
Related
A question is running into my mind for a several days ago.
I read several docs about vert.x and quarkus.
Which kind of message are sent throuh event-bus? Only received http request?
Has it sense to configure an clustered eventbus inside a quarkus application? Any example?
Those above question have not been able to find some lights.
Any ideas?
You can send any type of message through the Vert.x Event Bus, as long as a codec exists for this particular type. There are several built-in codecs, but you can register custom codecs too.
Quarkus does not support clustering officially so far. You can make it work with some tweaks, though.
From my perspective (I'm a Vert.x development team member), it can be useful to have a clustered eventbus inside Quarkus, just as it can be useful inside a Vert.x application. There are plenty of articles on the web about use cases.
I've recently been playing around with Spring Webflux and it looks extremely useful and efficient. Also, reading about Reactive Systems, it seems like one of the defining traits of such systems is that they are message-driven.
Came across this post on the web: https://www.captechconsulting.com/blogs/annotation-driven-reactive-web-apis-with-spring-webflux
This post also mentions,
Spring WebFlux contains support for Reactive HTTP Rest API(s),
WebSocket applications, and Server-Sent Events. Spring WebFlux is
responsive, resilient, scalable, and message-driven.
My question is that if a write a simple REST API, much like the post describes, performing CRUD operations backed by a MongoDB and using spring-boot-starter-data-mongodb-reactive, could I call my API service message-driven? I could also potentially add a Webclient to talk to some downstream services.
Does message driven in the context of a REST API even make sense?
No, your application is not message-driven instead your application are Reactive. Reactive applications is event-driven, non-blocking, scalable, resilient and elastic. It supports Publisher and Subscriber mechanism, means asynchronous communication is being done between Publisher and Subscriber. It supports two types of Publishers
Mono: Used when we produce only one item.
Flux: Used when we produce multiple items.
To make your application message-driven, you need to use any message broker like Kafka, RabbitMQ etc.
Is SignalR the same thing is Reactive Extensions? Can you explain why or why not?
No, they are absolutely not the same thing.
Reactive Extensions is a library for creating and composing observable streams of data or events (which are actually quite similar). It basically knows nothing about client-server connections or other things. It is focused solely on Observables and is capable of wrapping any collection, stream, event, async method, etc. into the common Observable interface.
SignalR is a toolkit for creating persistent (i.e. alive) duplex connections between client and server. It works over HTTP and its purpose is wrapping 3 low-level techniques: long-polling, server-side events and web sockets into a high-level API for comfortable development. So, it's focused on the communication.
So, the components themselves are quite independent from each other, and they have completely different concerns.
On the other hand, these 2 great libraries are complementary to each other: one might use SignalR to push events from server to clients and then wrap the server-side events into RX's Observables to create complex reactive user experiences.
UPDATE
Rx is like LINQ, it helps you specify 'what happens', it doesn't get into the details of 'how'. SignalR is a library to implement the 'how' for real-time network communication – Paul Betts
The difference between 'LINQ to Objects' and RX is that in 'LINQ to Objects' you pull next items from an enumerable thing, while in RX they are pushed to you from an observable thing.
I'm looking for a reference to a good implementation of event driven architecture based on Zend Framework. Could you share your experience in this topic?
I've found two solutions, but haven't used them yet:
http://framework.zend.com/wiki/display/ZFPROP/Zend_Event+-+Alvar+Vilu
http://components.symfony-project.org/event-dispatcher/
Edit:
Example:
http://www.slideshare.net/beberlei/towards-the-cloud-eventdriven-architectures-in-php
I don't have much practical experience in this topic, but since no one else seems to be replying, I suppose I'll share what I think of this...
This is perhaps a bit tricky thing in PHP apps, since they typically only run for the duration of a request, so the benefit of being able to subscribe and listen to generic events during that short phase may not be very large.
However, I think there can be some benefits in allowing you to decouple your code more.
From what I can tell, the Symfony dispatcher looks better - mainly because it looks simpler.
I've used a sort of dojo pubsub type system myself: Basically you have an event publisher, to which classes can publish events. This is a sort of global event handling, where you don't specifically subscribe to the class itself - instead you subscribe to a specific event, and it doesn't matter what class publishes the event.
The benefits of this vs. subscribing to a specific class is that the code is decoupled more: In my case, it's a ZF app, and classes which subscribe to events can simply do it in the bootstrap, vs. having to do subscriptions in controllers (or where ever the publishers are created)
The downside of this approach is that it can make dependencies between things harder to track. For example you only see an event publish call, but you have no idea what sort of things listen for it without digging further into the code.
In my case I don't really know if the application has got any benefits from using this architecture - in fact I've several times considered removing it entirely and just using the objects which listen to the events directly.
Most examples (if not all) that I see are the sort of a function that does some sort of computation and finishes. In that aspect, FP shines. However, I have trouble seeing how to apply it in the context of an enterprise application environment where there's not much of algorithms going on and a lot of data transfer and services.
So I'd like to ask how to implement the following problem in FP style.
I want to implement an events bus service. The service has a register method for registering listeners and publish for publishing events.
In an OO setting this is done by creating an EventBus interface with both methods. Then an implementation can use a list to hold listeners that is updated by register and used in publish. Of course this means register has a side effect. Spring can be used to create the class and pass its instance to publishers or subscribers of events.
How to model this in FP, given that clients of the event bus service are independent (e.g., not all are created in a "test" method)? As far as I can see this negates making register return a new instance of EventBus, since other clients already hold a reference to the old instance (and e.g., publishing to it will only publish to the listeners it knows of)
I prefer a solution to be in Scala.
I think you should have a closer look at functional reactive programming techniques. Since you want something in Scala, I suggest reading Deprecating The observer pattern paper by Ingo Maier, Tiark Rompf and Martin Odersky.
The sketch of the solution is that publish should return IO[Unit]. Listeners should be iteratees. Registration also returns IO[Unit].