I am very new to UM and am trying to integrate UM in our application. I have implemented the basic functionality of UM within our application - however am not sure if that is the best way.
Our application is a .Net Core web application which serves multiple users. The requirement is such that when a User performs a certain action, another application is called which performs an action and sends a message to UM. Our application is subscribed to these messages and we update our front-end browser with the latest data arriving from the other application.
Now, I have the below queries
I am ending up creating 1 connection per User to the UM realm. Is that correct? This would mean that the number of connections to the Server will be equal to the number of Users. Not sure if that is ideal
Ours is a web application. Hence there are chances that the application is kept open by the User on the browser. This would mean that the User’s “connection” to the realm is “Open”. What is the best way to handle this? We would not want any connections to be un-necessarily open.
I’d setup 1 connection per app instance instead of per user.
The initial connection could be triggered by user action but it ‘belongs’ to the app instance and subject the app usage pattern, close/reuse them accordingly.
Thank you for your response. The only problem with that is we are subscribing to a Topic with a filter criteria - the filter criteria being different for different users. So when I use the same “connection”, I am not able to add multiple subscriptions with different filter criteria
Hi all,
when talking about (messaging) connections, users and triggers you have to keep multiple architecture and security aspects in mind.
You can have multiple queues / topics, you can have a need to separate access / hide some of them from others.
e.g. the queues you want to allow input or provide output for from the ones that your application use internally.
You definitely also want to protect them for “sniffing” (listen to your data) as well as manipulation / deletion of data.
When thinking about the queues you may want to use different properties for persistence as well as latency, size or ttl for your events.
That explains why you may need an EntryQueue, ReplyQueue and maybe some internal Queues as well.
For each you might want to have different users, different ACL’s apply. So because of the different users also need different connections …
It’s best your first make some architecture picture (e.g. a flow diagram) to figure out what you really need in your use case.
“Same” connection can definitely have multiple trigger / filters. This is how IS works when it talks to UM.
