Comment concevoir des limitations individuelles pour les utilisateurs et les tables dans FastAPI

L'ingénierie logicielle est plus facile que nous ne le pensons car parfois les réponses sont simples et souvent sous nos yeux.

FastAPI m'a aidé à comprendre l'ingénierie backend et à réfléchir aux processus et à la façon dont les choses peuvent et doivent fonctionner. C'est un outil intelligent, cependant, il dépend uniquement de votre créativité et des yeux de votre imagination. Voici la prémisse de ma généralisation.

Si vous avez lu l'un de mes travaux précédents, vous savez que mon origine est Django (et son cadre de repos), et je suis reconnaissant pour sa direction et ses modèles de conception, ils m'ont permis de modifier la roue en fonction de mon cas d'utilisation.

En grandissant, ma pop savait que mon esprit se demandait et je voulais créer des trucs et ma pop m'a toujours dit qu'on ne pouvait pas réinventer la roue, la modifier.

Une fois, j'ai travaillé sur une application ou un point de terminaison limité/limité avec DRF et c'était incroyable, j'ai appris quelque chose de nouveau et j'ai été intrigué (plus tôt dans ma carrière). L'accélérateur dans ce cas a affecté les points de terminaison sur lesquels je l'ai appliqué, récemment j'étais intéressé à faire quelque chose de similaire dans FastAPI, et j'ai d'abord pris la voie facile (google pour la victoire) et j'ai vu qu'il existe des packages qui effectuent l'action d'accélérateur .

J'ai personnellement senti qu'ils offraient le même confort et la même familiarité que j'avais lorsque j'utilisais Django. Ils n'offraient pas la flexibilité que je voulais (ou peut-être que j'étais paresseux pour faire quelques remplacements), alors je me suis assis et j'ai conçu une solution. Examinons donc le code.

Avis de non-responsabilité : je ne fournirai pas d'informations sur la mise en route de FastAPI et je suppose que vous pouvez le faire, si vous ne pouvez pas consulter les meilleures ressources pour démarrer avec FastAPI ( Doc )

Application de démonstration : Tranzact, une application Fintechy (os nus).

Créons donc une table appelée Tranzact qui peut être utilisée pour créer des enregistrements de données Tranzact et une clé API serait générée pour pouvoir identifier des enregistrements Tranzact distincts.

Cette table et cette application exploitent SQLAlchemy, alors consultez la documentation.

Voici le routeur.

Nous pouvons effectuer des opérations CRUDy dans le routeur (si l'application a l'air bizarre, je ferai un autre article sur le modèle de conception ici appelé modèle de conception de référentiel).

C'est le point de terminaison auquel une clé API parle, cette clé API sert d'authentification pour effectuer certaines actions. Ce que nous pouvons voir, c'est qu'il existe une dépendance qui pointe vers un enregistrement de transaction.

Examinons la dépendance tranzact_header et vérifions les appels.

Cela reconnaît l'API_Key et renvoie l'enregistrement tranzact associé à une api_key.

Donc, pour résoudre le défi de la limitation individualisée, j'ai résolu cela lors de la création d'un enregistrement pour la table tranzact. Je crée un enregistrement avec le tranzact.id et un décompte avec une valeur par défaut de 0 dans le tableau de la limite de taux de tranzact. Voici le tableau ci-dessous.

Donc, avec cette solution, j'avais besoin d'un moyen de suivre l'enregistrement de la limite de débit, avec API_KEY, nous pouvons augmenter le nombre de manière incrémentielle en fonction de chaque appel et accélérer en fonction du rôle freemium de l'enregistrement tranzact. Voici à quoi ressemble la fonction.

Donc, avec cette fonction, nous pouvons faire de l'assurance qualité et vérifier en fonction d'un indicateur et du décompte. Cela dépend de la fonction api_header. Nous échangeons ensuite la dépendance dans les points de terminaison d'appel d'API avec la fonction de limite de débit d'API d'accélération. Nous pouvons le faire car ils renvoient tous les deux le même enregistrement Tranzact. Pour en savoir plus sur les dépendances et leur appel avec FastAPI consultez ce point de la documentation .

Voici un cas test dans mon facteur.

Configuration de l'API_KEY pour ma collection dans postman.

Vous trouverez ci-dessous la réponse limitée pour un appel de demande qui a atteint le nombre plafonné, ce qui signifie qu'une autre api_key répondra différemment en abandonnant la réponse souhaitée, et si l'enregistrement tranzact est premium, il contourne la vérification de la limitation.

C'est ainsi que j'ai créé un accélérateur d'enregistrement DB singulier, l'étape finale de mon implémentation comprend l'utilisation d'un travail de battement de céleri (un travail/tâche planifié) pour remettre à zéro tous les enregistrements de limite de taux de tranzact à l'heure. Il s'agit d'une implémentation personnelle, d'autres peuvent être faites.

En conclusion, prenez mes mots ci-dessous avec un cœur léger mais c'est ma vérité.

Tout produit/fonctionnalité que vous pouvez voir, imaginer ou conceptualiser, quelle que soit sa complexité, nous pouvons le construire, une fois que nous pouvons le voir, FastAPI peut nous aider à lui donner vie.

Également publié ici.