When making something like a chat application using Spring Websockets, it is useful to know who all is subscribed to any given topic. For, e.g. presence data displayed in the clients.
I know that I can implement ApplicationListener and keep my own list of "connected users", but it seems like the library must already be doing this work.
What's the recommended way to get active subscription info from the library directly (and without maintaining my own list in memory or db).
You're right, you could use ApplicationContext events, but unfortunately those events deal with user sessions events and broker events - so you won't be notified when a user subscribes to a particular topic.
You could do that when using the SimpleBrokerMessageHandler, by getting the SubscriptionRegistry. But again, the SimpleMessageBroker is not for production use.
If you're using RabbitMQ, you can get that information from its REST API.
The thing is, this is very specific to the broker implementation, so I'm wondering if a feature like that makes sense in Spring Framework. Could you open a JIRA issue to start the discussion?
Related
I want to keep track (with persistency) of users interactions with a microservice application developed with spring boot, so that i could consult them if something happened even maybe a year later.. One solution i found was use event sourcing and the problem was gone.. but due to some constraints i cannot go with that solution (in this project) so i was wondering..
Question
How can I track all user interactions and persist them in a spring boot microservice application?
if all the interactions that you want to track are sent to the server, then you can persist them in the database when the request is received in the server. To know who is the user you must need a way to identify him, for example, by using a token if the user is authenticated.
However, although this can be a solution the usual way to do this is using google analytics https://analytics.google.com/analytics/web/provision/#/provision
or snowplow https://snowplowanalytics.com/
Any of them track the actions done by the user in the frontend of the application
I'm currently working on a project that is a sort of an extension to an existing project.
Existing Project:
A product that is already there and has a pub/sub system of its own. It uses GraphQL.
Let's take an example.
There's a group (GROUP_1) and some users are a part of that group.
Let's say user A calls a mutation, the other users' sessions subscribed to that mutation get an update regarding the same(that A made these changes). The changes are reflected in their frontend accordingly.
What do we need?
Instead of user A making the change, we want to update when a third party service notifies us to make the change.
The thing is that the third-party service uses MQTT protocol and will give us a topic (for GROUP_1) to which it will publish the messages and we need to subscribe to it. Upon receiving the message if the message satisfies our condition we will call the mutation on behalf of the user the message specifies.
Problem
So we need the client to listen to that topic forever.
And there can be an addition to the topics provided. New groups can be added in the future. So we will have different topics for different groups(GROUP_1, GROUP_2, etc)
Research that I did
To have a client that listens to a topic permanently and we can add to that client new topics as we generate new GROUPS.
And then let this client update the GraphQL API eventually reflecting changes in the session of the users in that GROUP.
I think that's not the way MQTT should be used, we should make changes in the existing project but that is not in our hands as of now.
Constraint
We can't change the existing workflow of GraphQL mutation and subscription that the existing project has.
Questions
Is there a better approach to do this with the given constraint?
If not then how should we go about creating a client that listens permanently. Shall we have a server that's up for the same or is there a better way to do this?
Maybe I'm not understanding your post, but the solution seems pretty simple: Create a new client that subscribes to what the "third party service" publishes to, and then publish to the Topic that the existing clients subscribe to, all the info that was passed in by the 3rd party. The beauty of a Pub/Sub architecture is that adding functionality to an existing system is done by just adding a new set of clients...subscribers, publishers, or both. The existing system doesn't have to change at all, if you can reuse the existing Topics and data formats. So you create a "Proxy" that takes in the new info, and publishes out in the old format.
I have some experience doing REST microservices architecture, but now I want ot start using kafka as a message provider in my Event drivenr architecture.
I have an issue understanding how the communication works between microservices.
Lets say I have two microservices one that deals with users and another one with messages between users.
Users can be created, and then users can send another users messages, and I am planning to do them with topics and then store them in a MongoDB.
How do I retrieve this messages in a event driven architecture?
EDIT: The example is quite simple is just for educational purpose and to practice with Apache-Kafka.
For clarity, let's call user messages instead as posts.
One possible architecture is all users create post objects, which are sent to a Kafka topic that contains information such as timestamp, sender and sendee, rather than directly as a database insert.
Out of Kafka, you write some consumer process(es) to poll all messages from the topic, then insert to Mongo (and possibly also a search engine or machine learning / text categorization model).
On another user account, they (periodically) query the database for all posts sent to them, as Kafka is not indexable by a user account and one topic per user is not a scalable design pattern.
The gist is that users aren't directly retrieving posts from Kafka, but you've buffered messages in Kafka so they can be forked into different models so that you can decouple your application from a Mongo dependency (except for having a search feature)
From events, you can separate out "posts-new", "posts-edit", and "posts-deletes" as separate topics. For more context about designing this, you can look into Event Storming
I would like to understand what's the best way to implement a very simple message exchange system between two clients, using Spring Boot as back-end and AngularJS as front-end.
I'm new to Spring, I'm studying it and using it for a University project.
Let's say that my project is a kind of a simplified e-commerce. I want to create a "conversation" between two clients (for example, something like the messaging system on eBay) based on the exchange of simple text messages. If one of the clients is not connected, he has to be able to retrieve the messages received while he was offline.
I came across several tutorials and guides but most of them explain how to create a real time "chat room" which is not what I'm looking for.
I would like to have some suggestions on what would be the best path to follow (JMS, WebSocket...) and why.
Thanks in advance!
I need instances of a web-app to receive notifications via WebSocket.
These notifications derive from events in backend systems; these events need to be handled in multiple ways, not only pushed to clients.
Thus a pub/sub system is ideal: events are published and n consumers handle them if they are relevant for their operations (e.g. by topic).
Given my lack of knowledge on WebSocket I'm having a hard-time understanding the overall architecture I need to put in place.
In the pub/sub world consumers subscribe to queues of messages related to "topics" of interest to them.
Can the same be done in WebSockets? (i.e.: when connecting to a WebSocket from the browser, can I specify a set of topics that the client is interested in?).
If so, is it possible to directly connect to the pub/sub system or do I need a middle-layer that consumes from the pub/sub and pushes to websockets?
I guess that the answer to the last question depends on the pub/sub used and would need some library over WebSocket.
I am familiar with RabbitMQ, but I can choose another pub/sub system as at the moment nothing is in place so I have no migration costs.
Thanks