[PYTHON] FastAPI vs Vert.x Bench et impressions

Je cherchais un FW Python pour faire de l'IA une API, mais quand j'ai rencontré FastAPI et que je l'ai touché, cela semblait être très rapide, j'ai donc peur d'avoir déjà sélectionné Vertx dans le projet.

référence

Confirmé sur un serveur où Rails 6 est égal à 100 en même temps et à environ 250 req / s

Requests per second:    245.42 [#/sec](mean)
Time per request:       407.472 [ms](mean)
Time per request:       4.075 [ms](mean, across all concurrent requests)

Exemple de référence de programme qui renvoie simplement le texte OK FastAPI a commencé avec gunicorn-> uvicorn x4

100 simultanés

Vert.x - Kotlin

Requests per second:    3207.38 [#/sec](mean)
Time per request:       31.178 [ms](mean)
Time per request:       0.312 [ms](mean, across all concurrent requests)

FastAPI

Requests per second:    2703.43 [#/sec](mean)
Time per request:       36.990 [ms](mean)
Time per request:       0.370 [ms](mean, across all concurrent requests)

1000 simultanés

Vert.x - Kotlin

Requests per second:    3777.86 [#/sec](mean)
Time per request:       264.700 [ms](mean)
Time per request:       0.265 [ms](mean, across all concurrent requests)
Transfer rate:          1080.97 [Kbytes/sec] received

FastAPI

Requests per second:    2746.82 [#/sec](mean)
Time per request:       364.058 [ms](mean)
Time per request:       0.364 [ms](mean, across all concurrent requests)
Transfer rate:          413.10 [Kbytes/sec] received

10000 simultanés

Vert.x - Kotlin

Requests per second:    3736.25 [#/sec](mean)
Time per request:       2676.477 [ms](mean)
Time per request:       0.268 [ms](mean, across all concurrent requests)
Transfer rate:          1069.07 [Kbytes/sec] received

FastAPI

Requests per second:    3524.81 [#/sec](mean)
Time per request:       2837.034 [ms](mean)
Time per request:       0.284 [ms](mean, across all concurrent requests)
Transfer rate:          218.69 [Kbytes/sec] received

Impressions

L'API rapide est bonne. .. ..

• Pour une utilisation normale, vertx et Fast API auront à peu près la même vitesse. FastAPI merde vite
• FastAPI nécessite moins de code source, appelez immédiatement
• Les performances sont dans la plage d'erreur pour une utilisation pratique.

Il semble converger vers le problème de la préférence de la langue utilisée plutôt que du FW J'aime Vertx.

• L'EDI détecte les erreurs de manière très détaillée avant de fonctionner (saisie statique)
• Vous pouvez travailler sans vous soucier de la structure des répertoires
• Structure de projet facile à construire
• Vertx a également un bus événementiel et des rêves

Je voudrais défendre Vertx avec un discours de position qui a sélectionné la technologie, mais je ne me plains plus de la bonté de l'API Fast. FastAPI sera populaire. C'est déjà populaire. Vertx a toujours été un FW mineur. ..

FastAPI

• Génération automatique en temps réel de la documentation API
• Facile à recharger en temps réel pendant le développement
• Impression que les articles Web sont plus satisfaisants que vertx
• Extrêmement simple et facile à respecter
• Il est facile de se connecter à l'IA (devrait-il l'être?), Il semble donc que le backend puisse être complété avec Python.
• Tout le monde peut écrire le code avec la même visibilité → Super important
• On dirait que cela correspond à la tendance récente de rendre le côté serveur plus mince, plus léger et plus rapide.
• Si vous utilisez Docker, il semble facile à déployer.
• C10K d'accord
• Il semble que la session ne soit pas standard car elle est spécialisée en API. le problème est debout

Vertx

• Le plaisir de la saisie statique (avec Kotlin). Il signalera une faute de frappe même si cela ne démarre pas
• Profitez de tous les avantages de l'IDE. La complémentation et le refactoring se sentent comme une longue journée car il y a un IDE
• Facile à déployer à l'aide de fat-jar (j'aime le plaisir de terminer la construction du serveur avec Java)
• (I) Kotlin est amusant à écrire
• (Développé à l'aide de la bibliothèque OpenAPI) Le document API sera également généré automatiquement.
• Le meilleur de la lecture d'OpenAPI → important
• Il existe des ressources JVM telles que la journalisation (je ne suis peut-être pas familier avec Python, mais log4j est utile)
• Un rêve appelé bus événementiel
• C10K d'accord
• En fait, j'ai beaucoup de choses et je sens que je n'ai besoin de rien d'autre. Puisqu'il y a une session, il est facile de maintenir l'authentification avec un cookie de session de la manière traditionnelle
• Si vous voulez le faire, vous pouvez faire la DI au printemps. peut faire n'importe quoi

Comparaison avec d'autres frameworks

Puisqu'il s'agit d'un langage JVM et Python, il semble plus facile pour les ingénieurs de collecter qu'actix. Pour un usage professionnel, la plaque de fer Spring Boot ou .Net MVC semble être bonne car elle contient beaucoup d'informations.