Session instantiation about aiodynamo

[dimaqq]

You can totally do that. I’ve done it. It’s particularly meaningful in case of FastAPI, as there were issues with starlette and async contexts.

Your code as stated may be enough if your app never exits, eg runs until container is killed.

On the other hand, if your app is instantiated many times in tests, you can add a shutdown hook too to make the lifecycle cleaner.

[ojii]

Therefore my approach has been to create a session once upon the starting of my server like so:

your approach is similar to the one we use with fastapi, though we explicitly close the http session on app shutdown.

Would it be better to instantiate a new session every time I need to make queries to the database?

That would be worse. You could create aiodynamo.client.Client instances for each query if for some reason you want to do so, but the http session and (non-static) credentials instances benefit from being long lived. For http sessions it's so the http client can have a connection pool to re-use and for credentials it's to cache credentials if they're not static.

[dimaqq]

P.S. @torphix what kind of environment does your code run in? If it's a lambda, then a different set of concerns applies.

[torphix]

Thanks for getting back to me :)
The environment is indeed using AWS lambda + Mangum + AWS API gateway
What sort of alterations / design patterns changes should be adhered to?

[dimaqq]

That has it's own set of issues, incl. jordaneremieff/mangum#208 ➡️ jordaneremieff/mangum#211 in short, watch out for your on_event("startup") actually getting called for every request.

Basically you want to prioritise fast startup over everything else, and even then possibly use the lifecycle hooks.

Perhaps a global singleton is better... but then if lambda is suspended and resumed you may get errors or slowdown if the dynamodb key has expired... ultimately you probably need to use the lifecycle hooks 🤷🏻

[torphix]

Thanks!