Is it OK to have a long running coroutines in FastAPI?

Viewed 1050

Is it OK to have a 10-30 second coroutines in FastAPI?
(in the terms of FastApi performance and good practices)

So the client will have a request-response open for 10-30 seconds.
On the client side we are using React.js, so it's fine for them.

@app.get("/somepath")
async def read_item():
    async with aiohttp.ClientSession() as session:
        # some slow external API, 10-30 seconds
        async with session.get(f"https://external.website.com/{some_api_key}/") as response:
            response_json = await response.json()
            return response_json
2 Answers

it will work. so no problem on this side.

UX) it makes perfectly sens for big jobs. no need to optimise too much if the user understand why he waits and has a clear response when the data is ready/fails. you can implement a completion percentage if needed with socketio or sse (server sent events)

Perf) you can drastically reduce response time (hence performance and ux) by using caching. (if the call makes sens when cached) it will reduce response time and reduce the number of concurent requests to the server.

Is it OK to have a 10-30 second coroutines in FastAPI?

First of all, this is not a FastAPI question.

How many of these requests do you expect to have in parallel? Lots? Just a few? Do you want to limit how many coroutines you have running simultaneously? By default, asyncio will use as much resources as it possibly can. It might be what you want, it might not. If you want to limit how many coroutines can run at the same time and queue up requests, you might want to look at asyncio.Semaphore.

In regards to your question whether or not it's a good practice, it depends on your workflow. Asyncio was created especifically for this purpose, for long running background tasks to free up the application while they are doing their thing.

Now, if this is the best solution for your case, it's hard to tell without a clear picture of what your application is doing. What should happen if the user closes the browser while the request is still running in the server? The user wouldn't get a feedback about whether or not it completed successfully. Do you care about this scenario? If you do, you could consider using a queue and having a cronjob picking things up to process in the background.

Related