should I close the client after using?

[AlanWing]

Hi, this problem is might be a small one, but I'm just a little bit confused.

when I try to create a AsyncClient to post a request in an asynchronous web framework(FastAPI), I found out there are two options.

This was written by a colleague of mine.

async def translate_content(self, content: dict, *args, **kwargs):
    resp = await self.nlp_client.post(
        '/parser/v1/translate',
        json=content,
        timeout=settings.AI_SERVICE.nlp.translate_timeout or None
    )
    resp_json = resp.json()
    translated_json = Interpreter.transform_json(resp_json, 'data.result')
    return translated_json

and I wrote this one

async def search_similar_tags(self, tag: str, limit: int):
    async with self.nlp_client as client:
        response = (await client.get(
            url="/data_analysis/similarity_tags",
            params={"tag": tag, "limit": limit},
            timeout=settings.AI_SERVICE.nlp.translate_timeout or None
        )).json()
    if not response.get("result"):
        return False
    return response["result"]

the function intend to make a request proxy, self.client is httpx.AsyncClient()

so my question is, are we supposed to close the client after using?

my leader told me if we want to reuse the client in the next few requests, there is no need to close.

how about those database connections? why are they supposed to be closed?

[StephenBrown2]

The client connection should be closed at some point, as noted in the Disadvantages for HTTP Connection Pooling Wikipedia page.
However, Client settings and cookies and such do persist even when used in multiple context-managed blocks, as this is how I use the client in my usage, similar to yours.

Personally, I would re-write both functions to be fairly similar, as such:

async def translate_content(self, content: dict, *args, **kwargs):
    async with self.nlp_client as client:
        response = await client.post(
            "/parser/v1/translate",
            json=content,
            timeout=settings.AI_SERVICE.nlp.translate_timeout or None
        )
        response.raise_for_status()
    return Interpreter.transform_json(response.json(), "data.result")

and:

async def search_similar_tags(self, tag: str, limit: int):
    async with self.nlp_client as client:
        response = await client.get(
            "/data_analysis/similarity_tags",
            params={"tag": tag, "limit": limit},
            timeout=settings.AI_SERVICE.nlp.translate_timeout or None
        )
        response.raise_for_status()
    return response.json().get("result", False)

Of course, without closing the connections, would look like this:

async def translate_content(self, content: dict, *args, **kwargs):
    response = await self.nlp_client.post(
        "/parser/v1/translate",
        json=content,
        timeout=settings.AI_SERVICE.nlp.translate_timeout or None
    )
    response.raise_for_status()
    return Interpreter.transform_json(response.json(), "data.result")

and:

async def search_similar_tags(self, tag: str, limit: int):
    response = await self.nlp_client.get(
        "/data_analysis/similarity_tags",
        params={"tag": tag, "limit": limit},
        timeout=settings.AI_SERVICE.nlp.translate_timeout or None
    )
    response.raise_for_status()
    return response.json().get("result", False)

And you would need to close the connection at some point down the line. Personally I use Clients for multiple sequential related requests, and otherwise only for settings/header sharing (authorization being the most common), and so I would go for the first option, closing each request in it's own function. Happy to be shown wrong/a better way.

[tomchristie]

Interesting that we're not documenting this adequately, perhaps something to resolve there.

Generally you want a single client instance, that lasts for the lifetime of the application, and closes when the program terminates. The benefit there is that all connections will share the same connection pool, so sometimes outgoing HTTP requests won't need to establish a new connection, but can use an existing one.

With the sync case that's usually just done as a single global instance. The instance will automatically be closed when the object is __del__'ed.

Async code is more precise about instance cleanup, partly because you cannot automatically call asynchronous close operations from the synchronous __del__ method. You could use the FastAPI @app.on_event("shutdown") hook to close a global async client instance.

(I notice that their HTTPX docs open and close a single client inside a view, which is simple and convenient, tho not most beneficial from a connection pooling perspective.)

[AlanWing]

Thank you guys so much for the answers @StephenBrown2 @tomchristie , I've learned a lot. Actually I noticed that there is always a close() method to be called in aexit() or exit(), regardless of async or not. So context manager is always a good choice for me. Besides, close the resources after using is kind of a good habit(as far as I know). But I never thought about the thing of "re-use". Well then, now my point is that if the frequency of requesting is not much high(Maybe like few times per hour) , and there are many other clients who are sending requests to the server at the same time, better close it when it's done. If it just me myself who are sending(here I just make a proxy, receive requests from users and send to the server), then I can just leave it. Am I right?

[tomchristie]

Well then, now my point is that if the frequency of requesting is not much high(Maybe like few times per hour) , and there are many other clients who are sending requests to the server at the same time, better close it when it's done.

Yes, neat observation. If it's just a few requests per hour, then you won't gain anything from keeping idle connections open in the pool, since they'll time out after ~30 seconds, and won't get reused after that anyways.

In fact you'll be benefiting the server-side (in a very small way) by hogging less resources there.

As you say, being mindful with opening and closing resources is a good habit to cultivate.