Je bosse sur des environnements un peu similaires mais synchrones. Dans nos projets, on utilise flask-smorest, framework basé marshmallow, apispec, webargs. Il me semble que vous l'utilis(i|)ez aussi, j'avais eu des discussions avec des gens de chez vous sur Github. Et on utilise de plus en plus SQLAlchemy.
Au début j'ai utilisé flask-sqlalchemy mais je l'ai viré rapidement pour faire les quelques lignes de codes qui suffisaient. De mémoire, il apportait pas grand-chose et me gênait si je voulais accéder à la base sans passer par flask. En gros, c'était trop raccourci et j'étais plus à l'aise à faire un code que je comprenais. J'utilise scoped_session, et j'ai une classe qui reproduit une interface similaire à flask-sqlalchemy, avec une instance de db globale (créée à l'import) qui traîne partout dans le code et dont j'initialise l'accès à la base à l'init de l'application.
J'utilise souvent le combo ContextVar / ContextManager, en particulier pour passer des sessions. Je l'ai fait dans umongo (MongoDB ODM basé marshmallow) pour pouvoir faire des transactions sans passer la session via toute la pile de fonctions. Dans l'app sur laquelle je bosse en ce moment, j'ai une ContextVar CURRENT_USER que je renseigne dans le décorateur qui authentifie chaque route de l'app et que je lis dans la couche qui gère les permissions. Le coeur du code, qui contient la couche permissions, expose donc un context manager qui permet de renseigner l'utilisateur, et c'est ce context manager que j'utilise dans l'app.
Au passage, pour les permissions, j'ai utilisé Oso que j'ai découvert via le blog de StackOverflow et j'ai trouvé ça franchement pratique. Bien mieux que le code spaghetti maison que j'avais fait avant. Pour la peine, je viens de poster un lien ici.
Il y a un pain avec le formattage de code de ton article, après "Pour les curieux, voici la partie du code transmettant le contexte aux threads".
# Contextvars rulz et autres considérations
Posté par jihele . En réponse au lien FastAPI et SQLAlchemy – en asynchrone, attention aux faux amis. Évalué à 4. Dernière modification le 26 novembre 2021 à 18:46.
Salut.
Je bosse sur des environnements un peu similaires mais synchrones. Dans nos projets, on utilise flask-smorest, framework basé marshmallow, apispec, webargs. Il me semble que vous l'utilis(i|)ez aussi, j'avais eu des discussions avec des gens de chez vous sur Github. Et on utilise de plus en plus SQLAlchemy.
Au début j'ai utilisé flask-sqlalchemy mais je l'ai viré rapidement pour faire les quelques lignes de codes qui suffisaient. De mémoire, il apportait pas grand-chose et me gênait si je voulais accéder à la base sans passer par flask. En gros, c'était trop raccourci et j'étais plus à l'aise à faire un code que je comprenais. J'utilise scoped_session, et j'ai une classe qui reproduit une interface similaire à flask-sqlalchemy, avec une instance de db globale (créée à l'import) qui traîne partout dans le code et dont j'initialise l'accès à la base à l'init de l'application.
J'utilise souvent le combo ContextVar / ContextManager, en particulier pour passer des sessions. Je l'ai fait dans umongo (MongoDB ODM basé marshmallow) pour pouvoir faire des transactions sans passer la session via toute la pile de fonctions. Dans l'app sur laquelle je bosse en ce moment, j'ai une ContextVar CURRENT_USER que je renseigne dans le décorateur qui authentifie chaque route de l'app et que je lis dans la couche qui gère les permissions. Le coeur du code, qui contient la couche permissions, expose donc un context manager qui permet de renseigner l'utilisateur, et c'est ce context manager que j'utilise dans l'app.
Au passage, pour les permissions, j'ai utilisé Oso que j'ai découvert via le blog de StackOverflow et j'ai trouvé ça franchement pratique. Bien mieux que le code spaghetti maison que j'avais fait avant. Pour la peine, je viens de poster un lien ici.
Il y a un pain avec le formattage de code de ton article, après "Pour les curieux, voici la partie du code transmettant le contexte aux threads".