I have a single page app that may have 1..n atmosphere subscriptions to a topic (the subscription is typically tied to a component that the user adds to the screen). An issue I'm coming across is when I call unsubscribe on a single request, it unsubscribes from ALL of the requests. You can see an example of the front-end at http://pastebin.com/c113bCNY . I am able to successfully establish both connections, and both receive message updates independently, but when I call $.atmosphere.unsubscribe(requestOne); The onClose event fires for both and I can confirm on the server it is also closing down both subscriptions.
On the server-side, I'm using the MeteorServlet in a Spring MVC environment. (See http://pastebin.com/2Ub83LdZ for the relevant parts) Is there something additional I need to do to isolate the two subscriptions?
Versions:
jQuery.atmosphere = { version: "2.2.13-jquery"}
<dependency>
<groupId>org.atmosphere</groupId>
<artifactId>atmosphere-runtime</artifactId>
<version>2.3.5</version>
</dependency>
Thanks in advance.
$.atmosphere.unsubscribe(request) DOES cancel the entire socket connection (it ignores the request parameter). Apparently that is by design. To cancel a single subscription call the disconnect() method on the subscription object you get back from $.atmosphere.subscribe.
Related
I'm working on a chat app, developed using Apollo GraphQL and React and I have the following issue:
I have a component called "Conversation" which is fetching an array of messages between two users (the logged-in user and other user) using the "useQuery" hook of Apollo which is invoked every time the component mounts.
When a new message is sent by the logged-in user, I'm updating the cached array of messages using the "writeQuery" function provided by Apollo.
By doing that, the "Conversation" component is getting re-rendered, which is leading to an unnecessary network request because the "useQuery" hook is triggered again.
I would love to hear if there is a way of preventing "writeQuery" from triggering a re-render to the relevant component.
Thanks a lot in advance!
I've been using Redis's Pub/Sub a bit in my application and so far it has been great. I am able to send out a Publish out of Laravel to a different backend process that is able to Subscribe, and eventually Publish an event back to Laravel.
The use case for the user looks like:
submit a form -> wait for a response (a few minutes) -> proceed with transaction
On the backend:
the form posts to a route, then to a controller that publishes this to a subscribed 3rd party (channel one), and eventually that 3rd party publishes back (channel two)
Main Issue: I don't know where the appropriate place to be for subscribing to the (channel two) and processing what gets published there.
Ideally, I'd be able to process Publish requests in two ways:
Letting the user know that their form has been processed and they can move onto the next step (probably with an update to a property a Vue component)
Storing information from the publish into my database.
In the docs, they have it in a Command, which if I try to use here would look like so:
public function handle()
{
Redis::subscribe('channel-two', function ($message) {
// update the client so that the user moves on
// send $message contents to the database
});
}
but that doesn't really seem ideal for me since I want this channel subscribed to 24/7, always listening. Even if it is in a Command, it is still apparent how I would best update the client.
Where in my Laravel project should I be subscribing at? Is there a best practice to respond to these events?
Redis::subscribe is used in a command like in that example for listening on a given channel continuously.
From the docs:
First, let's setup a channel listener using the subscribe method. We'll place this method call within an Artisan command since calling the subscribe method begins a long-running process:
You'll want to run the command using a process manager like supervisor or pm2, much the same as the docs describe running queue listeners.
I'm developing a project with Symfony 3.4.
I would like to send a message to all the clients currently viewing a page when something happens. I evaluated both Server-Sent Events and Websockets, and I decided to go with the former, because the communication is unidirectional (only server to client).
For this purpose, I'm using this library: https://packagist.org/packages/tonyhhyip/sse
It seems to work, but I need to specifically send a message when something happens in the whole system. I tried with the Symfony event system (by creating a custom event), but events seem to be dispatched and captured only within the same session (i.e., the same logged user). In other words, if an action performed by a user triggers an event, it is not captured by other users and therefore a message is not sent to the browser via SSE.
Any suggestion?
Thank you
Let suppose the following simple UC based on a CQRS architecture:
We have a backend managing a Business Object, let says a Movie.
This backend is composed of 2 Microservices: a CommandManager (Create/Update/Delete Movie) and a QueryManager (Query Movie)
We have a frontend that offer a web page for creating a new Movie and this action lead automatically to another web page describing the Movie.
A simple way to do that is:
A web page collect movie information using a form and send them to the frontend.
The frontend make a POST request to the CommandManager
The CommandManager write the new movies to the datastore and return the movie key
The frontend make a GET using this key to the QueryManager
The QueryManager looks for the Movie in the Datastore using the key and return it.
The frontend deliver the page with the Movie Information.
Ok, now I want to transform this UC in a more Event Driven way. Here is the new flow:
A web page collect movie information using a form and send them to the frontend.
The frontend write a Message in the BUS with the new movie information
The CommandManager listen the BUS and create the new movies in the datastore. Eventually, it publish a new message in the BUS specifying that a new Movie has been created.
At this point, the frontend is no more waiting for a response due to the fact that this kind of flow is asynchronous. How could we complete this flow in order to forward the user to the Movie Information Web page? We should wait that the creation process is done before querying the QueryManager.
In a more general term, in a asynchronous architecture based on bus/event, how to execute Query used to provide information in a web page?
In addition to #VoiceOfUnreason's answer,
If the two microservices are RESTFul, the CommandManager could return a 202 Accepted with a link pointing to the resource that will be created in the future. The client could then poll that resource until the server responds with a 200 OK.
Another solution would be that the CommandManager would return a 202 Accepted with a link pointing to a command/status endpoint. The client would poll that endpoint until the status is command-processed (including the URL to the the actual resource) or command-failed (including a descriptive message for the failure).
These solutions could be augmented by sending the status of all processed commands using Server Sent Events. In this way, the client gets notified without polling.
If the client is not aware that the architecture is asynchronous, a solution is to use an API gateway that blocks the client's request until the upstream microservice processes the command and then to respond with the complete resource's data.
At this point, the frontend is no more waiting for a response due to the fact that this kind of flow is asynchronous. How could we complete this flow in order to forward the user to the Movie Information Web page? We should wait that the creation process is done before querying the QueryManager.
Short answer: make the protocol explicit.
Longer answer: a good place to look for inspiration here is HTTP.
The front end makes a POST to the origin server; as a result the origin server places a message on the queue and sends a response back.
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
The client can then poll the endpoint to find out what progress has been made.
For instance, the endpoint might be a query into the data store, that looks for evidence that the command manager has processed the original command; or it might be an endpoint that is watching the bus for the MovieCreated message, and changes its answer based on whether or not it has seen that.
It may help clarify things to look into idempotent request handling; when the Command Manager pulls a message off of its queue, how does it know if it has previously processed a copy of that message? Your polling endpoint should be able to use the same information to let the consumer know that the message has been successfully processed.
In addition to #Constantin Galbenu's answer, I would like to put in my two cents.
I would strongly advise you to look at a microservices pattern called "BFF" (Backend-For-Frontend) pattern. Instead of having a thick API gateway doing all the work, you can have an API per use-case. For Example: In your case, you can an API called "CreateMovieBFFHandler" which would receive the POST request from front-end and then this guy would coordinate with other things in the system like message queues, events etc. to track the status of the submitted request. UI might have a protocol with this BFFhandler that if the response doesn't come back in X seconds, then the front-end would consider it as failure and if this handler is able to get a successfully processed messaged from message queue or "MovieCreated" event for this key, then it could send a 200 OK back and then you can redirect the page to call write side and then populate the UI.
Useful Link: https://samnewman.io/patterns/architectural/bff/
I have an ASP.NET Web API server, that have to communicate with different applications on different platforms. And now I want to create a method that would be something like a callback: client application subscribes to it and waits until server fires a message.
Example:
Many users are waiting until new product will be available in store - they subscribe to this "event". When product arrives in store - every customer receives a message, which have to be handled in some case.
Users send a request "Subscribe"
Server receive a request "Product available!"
Server sends every user a message with product details.
User's application processes the message
I tried to find some information about callbacks or duplex in ASP.NET Web API, but the one advice - it's better to use WCF for this approach.
Solutions
In every client application create something like timer, that every N seconds sends a request "Is product available?" until gets "false". When the response will be true - send a message "Get product details". It's causes a lot of traffic and if there will be many clients with these timers - it would be something bad, isn't it?
Create a small callbacks-server (maybe WCF). But in this case would be a lot of problems with communication between this server and apps on different platforms.
Maybe there are some solution in ASP.NET Web API, that i missed.
If you have some ideas how i can solve this problem, please give me an advice.
Thanks for help.
Looks like you want push notifications from your server - which, in this case, can be achieved by combining SignalR with Web API.
Brad Wilson has a great example on this:
code here - https://github.com/bradwilson/WebstackOfLove
NDC Oslo talk explaining all this - http://vimeo.com/43603472
In short, whenever you add new item to the Web API, you can notify all the connected (subscribed) clients:
public void PostNewItem(ToDoItem item)
{
lock (db)
{
// Add item to the database
db.Add(item);
// Notify the connected clients
Hub.Clients.processItem(item);
}
}
SignalR will invoke the processItem function on the client.
Alternatively, you might want to look into JavaScript SSE and Web API PushStreamContent but that is much more low level and SignalR abstracts a lot of this type of stuff for you so it might be more complicated to deal with.
I blogged about this approach here http://www.strathweb.com/2012/05/native-html5-push-notifications-with-asp-net-web-api-and-knockout-js/