Avoiding long running HTTP API requests.

How would you design an HTTP API that needs to generate a transcript for a specific video (by id)? Deeper into that question, you can assume that won't be a fast request/response so how can we better manage this? Using asynchronous request/reply with HTTP.

🔗 EventStoreDB

💥 Join this channel to get access to a private Discord Server and any source code in my videos.

🔥 Join via Patreon

✔️ Join via YouTube

[CodeOpinion]

Want to learn more about software architecture and design? Join thousands of developers getting weekly updates!

[HylandorVT]

Another option, if available, is the caller provide a callback so the long running process can tell the caller when to fetch

[nitrovent]

If it has to be some REST style API, I'd do both. 1. POST the id to the service to enqueue/start the conversion. 2. Have a GET endpoint like /status?id={id} to query the status and do polling or let the user refresh the status manually in the UI. Otherwise some kind of messaging via a queue could be nice.
The id in the GET could also be a job id the POST would return.

[joelv]

Any long running process is screaming for a job queue. So the HTTP handler should validate the request, add it to the queue, and return the job id or maybe a url where the status can be fetched.

[dzikiLOS]

One thing that I would change here is to use server sent events for updates and http for initiating processes. In my experience websockets tend to get very chatty and maintaining one way communication from server to client and easier and simplier

[JamesQQuick]

Ooooh love the take! 100% agreed on long standing requests. One of my issues is trying to solve this problem in serverless where I don't have access to process queues, cron jobs, etc. Thanks for doing this take!

[ransandu]

Option 1: Queue/topic (pub/sub)
Submit the request with a traceable/trackable id to a queue. (caller become the publisher)
transcript generation process subscribes to this queue.
then the caller subscribes to a transcript completed event from the transcript generation process.
use the traceable id to correlate the incoming messages to grab the transcript.

Option 2: Request/WebHook
Make a fire-and-forget request to the transcript generation service (with a traceable id).
The transcript generation service then posts the result to a webhook exposed by the service that made the request. Use the traceable id to correlate messages.

[adambickford]

Also, make your UI reflect the processing. Don't be afraid to show a queue and status to the user vs trying to pretend its really a blocking req/resp interaction.

[mravacado]

How can you draw the line between "long running" and "very long running"? If the endpoint returns in less then 10 seconds for example, is it ok to return the results without the need for pulling?

[Airbone]

What do you think about the client subscribing to a message on a response queue

[kennedymwenda]

Now that we're talking about e-commerce, do we reduce stock levels immediately the order is submitted or asynchronously? If asynchronously how we alert for item out of stock if inventory ran out during the asynchronous process by another shopper?

[xpeter]

Your are completely right about the solutions, but I will say I have seen plenty of examples of people making overcomplicated asynchronous architectures for sometime they can resolve synchronously well within the 60 seconds timeout. Expecially combined with good explanations in the UI. Generally I always ask my self 3 times if I REALLY need to make a asynchronous solution in this case, since it bring so many problems with it.

[PaulPendor]

53 seconds into the video, and I am going to suggest utilising a WebHook pattern to return the result to the caller once the process is complete. Initial request is a quick POST.

[KristjanBroderLund]

I like the original question posed in the video. Different scenario: If the url to the transcript a canonical url that should be cached, and you want to create the transcript lazily (on demand), e.g. If the url is /video/{id}/transcript, you'd probably want to have it long running until it's done and cache the result for subsequent requests.

[georgehelyar]

If any replica of the consumer is able to pick up the result later then 202 accepted followed by an event on a message broker, which could then go to a webhook if the consumer is external, but if you want it to go back to a specific consumer then you might have to deal with asynchronous request/reply which can add complexity e.g. you want the response to go back to a specific consumer and that consumer may disappear before the response is published, and then you might have to clean up any claim check payload when it eventually dead letters etc.

Wouldn't use polling though.

If it really has to go back to a specific consumer and if they disappear you can just stop then just make it synchronous. Could use gRPC here and maybe even stream the response back as it becomes available.

Maybe even RTMP depending on the use case (e.g. if you are streaming subtitles to a media player then don't reinvent the wheel)

[minhduccao]

what if in the business process we got an exception throw from the code, should we use email to communicate back to client about this ? any thought on this

[GnomeEU]

Isn't there some kind of synchronous request option to the server? In 99% of cases if we click something we want the result. Updating a div 5 seconds later asynchronously always sounded weird to me. There's nothing asynchronous about displaying a loading gif anyway. The User often can't click something else or should not while waiting. So I always wondered why some synchronous button is not the default. It's the much more common use case and would make development a little bit easier.

[bjornsandberglynch]

If you're not using websockets and there's a reasonably accurate way to estimate the task duration (in this example, video file size) you can provide an ETA for completion to the client. This helps e.g. sizing the progress bar on the client and avoids incurring server load by starting to poll for a result that isn't available yet.

[thedacian]

What about using javascript SSe instead of websockets for sending resource URI to the js client?

[nobel]

If we use websockets, what happens if the client misses the response due to connection issue? Should websocket messages be persisted and client can continue reading messages from last starting point like a chat session?