CODEWITHSUNDEEP
.netazureazure-functionsqueueazureservicebus
Krzysztof
Krzysztof

Reputation: 192

Azure Service Bus add get requests to queue

So I am having so problems with desining queue, my API application to gather data needs to call another endpoint, so to avoid too many requests I wanted to put those requests into the Azure service bus queue, but from what I learnt it is great way for updating/inserting data, but when it comes to read data I am having trouble understanding how I can return processed data to the front (UI) once its being processed.

I came up with idea that when front request data, I put it into the queue and return message id to front, then in queue I will use Azure Function to call my service endpoint which will get the data and insert into my database as json payload.

Once request has been finished I will change request status to Complated and front will do pulling to check message state every 5-10 sec or use SignalR for real time checking.

Is there anybetter solution that the one that I mentioned above? I think its too complex and data redundancy might be a problem.

Thanks in advance!

I am trying to create a queue for heavy get requests

Upvotes: 0

Views: 635

Answers (2)

Christian Vorhemus
Christian Vorhemus

Reputation: 2663

A queue is especially useful when a publisher sends more messages than a receiver can process and you want to decouple these two entities so the receiver doesn't get overwhelmed with requests. If your goal is to slow down the number of requests hitting the other endpoint you are calling while keeping the possibility for users of your API to keep firing requests, the process you described is a standard way to handle this scenario. Here is a sample illustration: enter image description here Assuming your API allows users to post jobs, you create a UUID and send it back to the user/GUI as well as enqueuing the message in an Azure Service Bus. If you want to enforce FIFO processing, make sure to use sessions. On the receiver end you add an Azure Function with a service bus trigger which calls your other endpoint (you can control the maximum number of instances your Azure Function can scale to by setting WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT to avoid overwhelming your other endpoint). If the other endpoint processed the request and responded, you store the result in a database of your choice and mark the message in Azure Service Bus as complete. If you use CosmosDB, you can make use of the change feed feature to listen on new entries and send them to the WebSocket server which maintains the open connections to the users. Keep in mind that the WebSocket connection can close unexpectedly so it might be a good idea to give users an URI to lookup the results once they posted the job.

Upvotes: 1

Sean Feldman
Sean Feldman

Reputation: 25994

A web request is a synchronous operation in its nature. Durable messaging is asynchronous. Mixing the two requires to bridge the gaps and it’s never trivial. Polling is not ideal as with the growing number of clients it will tax your web server. SignalR is a better option to callback a specific client that needs to know the result.

The flip side of this solution is building the client side in a way we’re updates or calculations results are eventual rather than immediate.

Upvotes: 1

Related Questions