Posté par jihele .
É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".
On utilise plusieurs "stack" à Algoo, selon les projets :
Pyramid / SQLAlchemy pour Tracim,
Flask sur notre site web,
Django sur certains projets internes et projets clients,
Là, on est intervenu sur du FastAPI sur un projet client,
…
Dans tous les cas, SQLAlchemy c'est quasiment LA brique récurrente car y'a pas vraiment d'équivalent (ça fait plus de 10 ans que je l'utilise, personnellement, et j'ai pas rencontré de cas où ça posait problème)
Si tu utilises apispec pour les API,peut-être que Hapic pourrait t'intéresser. C'est une brique "framework agnostic" pour construire des APIs REST robustes, documentées et gérant les erreurs de manière standardisée. On l'utilise sur Tracim, sur des projets clients notamment développés sur base Flask ou aiohttp (et historiquement bottle) …
le principal développeur de Hapic est chez Algoo et rôde sur LinuxFR (et parfois il est même récompensé pour ses dépêches et les jeux vidéos qu'il développe ;)
Ça me revient, en effet, c'est avec toi que j'avais échangé sur apispec que vous utilisez dans Hapic. Ca remonte un peu et on avait un gros refactor en cours sur apispec. C'est plus calme maintenant. C'est vrai aussi pour webargs et marshmallow.
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.
Aujourd'hui j'ai vu passer Oso sur le canal interne de veille techno … je suppute que ça vient de ton message 😃
Je m'étais cassé la tête à trouver des solutions pour faire de l'autorisation avec des périmètres, pas juste du RBAC (un utilisateur peut lire les documents), mais la possibilité par exemple de dire qu'un utilisateur peut lire les documents qui sont dans son groupe.
J'avais rien trouvé d'utile. Pour le RBAC, il y a du monde, mais dès qu'il y a en plus du relationnel, c'est tout de suite métier et on trouve pas de code générique.
Oso est arrivé à pic. La partie relationnelle est bien abstraite. Pour l'instant je suis assez bluffé.
# Blocages et pertes de données dans un projet FastAPI
Posté par Algoo (site web personnel) . Évalué à 2.
Récit de l’investigation d’un bug apparemment peu grave, mais fondamentalement critique.
[^] # Re: Blocages et pertes de données dans un projet FastAPI
Posté par Anonyme . Évalué à 3.
le lien sans le traceur c'est mieux
[^] # Re: Blocages et pertes de données dans un projet FastAPI
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
C'est corrigé, merci.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Contextvars rulz et autres considérations
Posté par jihele . É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".
[^] # Re: Contextvars rulz et autres considérations
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Bonjour jihele,
On utilise plusieurs "stack" à Algoo, selon les projets :
Dans tous les cas, SQLAlchemy c'est quasiment LA brique récurrente car y'a pas vraiment d'équivalent (ça fait plus de 10 ans que je l'utilise, personnellement, et j'ai pas rencontré de cas où ça posait problème)
Si tu utilises apispec pour les API,peut-être que Hapic pourrait t'intéresser. C'est une brique "framework agnostic" pour construire des APIs REST robustes, documentées et gérant les erreurs de manière standardisée. On l'utilise sur Tracim, sur des projets clients notamment développés sur base Flask ou aiohttp (et historiquement bottle) …
le principal développeur de Hapic est chez Algoo et rôde sur LinuxFR (et parfois il est même récompensé pour ses dépêches et les jeux vidéos qu'il développe ;)
[^] # Re: Contextvars rulz et autres considérations
Posté par bux (site web personnel, Mastodon) . Évalué à 2.
Coucou !
J'utilise également beaucoup aiohttp maintenant. Toujours couplé à SQLAlchemy manuellement un peu comme toi @jihele .
Et pis, bon, en vrai ces derniers temps je code en Rust :D
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
[^] # Re: Contextvars rulz et autres considérations
Posté par jihele . Évalué à 2.
Ça me revient, en effet, c'est avec toi que j'avais échangé sur apispec que vous utilisez dans Hapic. Ca remonte un peu et on avait un gros refactor en cours sur apispec. C'est plus calme maintenant. C'est vrai aussi pour webargs et marshmallow.
[^] # Re: Contextvars rulz et autres considérations
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Aujourd'hui j'ai vu passer Oso sur le canal interne de veille techno … je suppute que ça vient de ton message 😃
[^] # Re: Contextvars rulz et autres considérations
Posté par jihele . Évalué à 3.
Je m'étais cassé la tête à trouver des solutions pour faire de l'autorisation avec des périmètres, pas juste du RBAC (un utilisateur peut lire les documents), mais la possibilité par exemple de dire qu'un utilisateur peut lire les documents qui sont dans son groupe.
J'avais rien trouvé d'utile. Pour le RBAC, il y a du monde, mais dès qu'il y a en plus du relationnel, c'est tout de suite métier et on trouve pas de code générique.
Oso est arrivé à pic. La partie relationnelle est bien abstraite. Pour l'instant je suis assez bluffé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.