We make several long-running, async, API calls using the Jsonclient to a ServiceStack host. These calls perform a number of closely linked tasks. I would like to obtain some feedback as to the current progress.
I can easily report back at which step the call failed, but I would like to provide more feedback to the user on when each stage completes.
It is not practical or even desired, to make individual calls to the API Host for each step.
We could use our Rabbit Messaging infrastructure to report back statuses, but that seems wrong.
I can see there is some feedback on upload and download operations as to x of y bytes... Perhaps there is a way we could hijack this, and send back stages 1 of 5, 2 of 5, etc.
How do other people provide feedback on long-running API calls when using ServiceStack?
You'll need a separate channel to communicate back any API updates which I'd use Server Events for with both server and client sending and listening to the same channel for progress events. If you send events with NotifySession only the current browser session will receive the updates.
Related
I'm building an application in which we have worked on Payment gateway named flutterwave.
And now the scenario is on every success or failure of a payment, I receive a webhook and then we take further actions such as sending emails, SMS and updating the statuses of the payment in the DB.
For now, we have implemented polling in the client side and for a particular time span if the client receives a status (success or fail) we show it otherwise they can check later it in the payment history page.
Now we want to remove this polling and update users in real time about the success or failure of a payment.
What are the ways by which we can achieve this?
The questions are how we will notify a specific user about the same as we have a multiplatform app and the same user can be logged in different platforms.
What you are looking for is a real-time communication pattern with WebSockets a layer 7 protocol in the OSI model which offers bi-directional communication.
This means that you can establish communication between your servers and your user's browser (client). As a result, you can send notification data to the client and consume and react to the notification, by showing visual cues in your UI for the user to see.
Some examples of implementing WebSockets with Socket.io and Nodejs: https://dev.to/novu/sending-real-time-notifications-with-socketio-in-nodejs-1l5j
There are also paid services that can offer this functionality like Pusher, and I would actually recommend that route at the beginning so you can avoid spending too much time implementing this and focus more on the stuff that matters and is part of your roadmap.
Additionally, you can use Push Notifications as another way to notify your users even when they are not using the app.
I'm trying to understand how to do two-way communication with google pub-sub with the following architecture
EDIT: I meant to say subscribers instead of consumers
I'm trying to support the following workflow:
UI sends a request to an api service to process an async process
API Service publishes request to a topic to begin the process kick-off
The consumer picks up the message and processes the async process service.
once the async process service is done it publishes to a process complete topic.
Here is where I want the UI to pick up the process complete message and I'm trying to figure out the best approach.
So two questions:
Is the multiple topic the preferred approach when wanting to do two-way communication back to the client? Or is there a way to do this with a single topic with multiple subscriptions?
How should the consumer of the Process-Complete get the response back to the UI? Should the UI be the consumer of the subscription? Or should I send it back to the api service and publish a websocket message? Both these approaches seem to have tradeoffs.
Multiple topics are going to be preferred in this situation, one for messages going to the asynchronous processors and then one for the responses that go back. Otherwise, your asynchronous processors are going to needlessly receive the response messages and have to ack them immediately, which is unnecessary extra delivery of messages.
With regard to getting the response back to the UI, the UI should not be the consumer of the subscription. In order to do that, you'd need every running instance of the UI to have its own subscription because otherwise, they would load balance messages across them and you couldn't guarantee that the particular client that sent the request would actually receive the response. The same would be true if you have multiple API servers that need to receive particular responses based on the requests that transmitted through them. Cloud Pub/Sub isn't really designed for topics and subscriptions to be ephemeral in this way; it is best when these are created once and all of the data is transmitted across them.
Additionally, having the UI act as a subscriber means that you'd have to have the credentials in the UI to subscribe, which could be a security issue.
You might also consider not using a topic for the asynchronous response. Instead, you could encode as part of the message the address or socket of the client or API server that expects the response. Then, the asynchronous processor could receive a message, process it, send a response to the address specified in the message, and then ack the message it received. This would ensure responses are routed to where they need to go and minimize the delivery of messages that subscribers just ack that they don't need to process, e.g., messages that were intended for a different API server.
I have a process in the back-end which will take take on average 30 to 90 seconds to complete.
Is it better to have a font-end react app make ONE API call and wait for back-end to complete and process and return the data. Or is it better to have the front-end make multiple calls, lets say every 2 seconds to check if the process and complete and get back the result?
Both are valid approaches. You could also report status changes with websocket so there's no need for polling.
If you do want to go the polling route, the general recommendation is to:
Return 202 accepted from your long-running process endpoint.
Also return a Link header with a url to where the status of the process can be read.
The client can then follow that client and ping it every x seconds.
I think it's not good to make a single API call and wait for 30-90 seconds to get a response. Instead send a response immediately mentioning that the request is successful and would be processed.
Now you can use web sockets or library like socket.io so that the server can communicate directly to the client once the requested processing is complete.
The multiple API calls to check if server is done or server has any new message is called polling and is not much efficient but it is still required in old browsers which don't support web sockets. Socket.io support s polling automatically in old browsers.
But, yes if you want you can do multiple calls to check if server is done processing, but I would prefer server to communicate back to the client , it is better.
I'm trying to figure out how I can send multiple requests to let the client know that uploading and processing has finished.
For example: Let the client know that upload has finished, and processing has started. When processing has been finished, send another request to notify the client.
I only want to know the proper functions to use because it seems that sending two res.write()'s wont send until I call res.end()...
You actually want to inform the client about updates that happen asynchronously on the server / in the backend.
From the top of my head, there are a few ways to achieve getting asynchronous information to the client:
Open a stream and push updates via the stream to the client (for example, using server-sent-events)
Open a websocket and push your messages to the client (you need to manage the HTTP and websocket connections to write to the correct one)
Create a new route to let clients subscribe to information about the status of a job (some example code)
I'd select one of the solutions depending on your current client design. If you have something like websockets already available, I'd use that - but it's quite something to setup, if you don't. Streaming might not work cross-browser, but is quite easy to build. For the third option, you probably need more housekeeping in order to not create some memory leaks if a client disconnects.
Given an event driven micro service architecture with asynchronous messaging, what solutions are there to implementing a 'synchronous' REST API wrapper such that requests to the REST interface wait for a response event to be published before sending a response to the client?
Example: POST /api/articles
Internally this would send a CreateArticleEvent in the services layer, eventually expecting an ArticleCreatedEvent in response containing the ID of the persisted article.
Only then would the REST interface response to the end client with this ID.
Dealing with multiple simultaneous requests - is keeping an in-memory map of inflight requests in the REST api layer keyed by some correlating identifier conceptually a workable approach?
How can we deal with timing out requests after a certain period?
Generally you don't need to maintain a map of in-flight requests, because this is basically done for you by node.js's http library.
Just use express as it's intended, and this is probably something you never really have to worry about, as long as you avoid any global state.
If you have a weirder pattern in mind to build, and not sure how to solve it. It might help to share a simple example. Chances are that it's not hard to rebuild and avoid global state.
With express, have you tried middleware? You can chain a series of callback functions with a certain timeout after the article is created.
I assume you are in the context of Event Sourcing and microservices? If so I recommend that you don't publish a CreateArticleEvent to the event store, and instead directly create the article in the database and then publish the ArticleCreatedEvent to the Event store.
Why you ask? Generally this pattern is created to orchestrate different microservices. In the example show in the link above, it was used to orchestrate how the Customer service should react when an Order is created. Note the past tense. The Order Service created the order, and Customer Service reacts to it.
In your case it is easier (and probably better) to just insert the order into the database (by calling the ArticleService directly) and responding with the article ID. Then just publish the ArctileCreatedEvent to your event store, to trigger other microservices that may want to listen to it (like, for example, trigger a notification to the editor for review).
Event Sourcing is a good pattern, but we don't need to apply it to everything.