[PYTHON] FastAPI vs Vert.x Benchmarks and impressions

I was looking for a Python FW to make AI an API, but when I encountered FastAPI and touched it, it seemed to be very fast, so I'm afraid that I had already selected Vertx technology in the project.

benchmark

Confirmed on a server where Rails 6 is 100 at the same time and 250 req / sec

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)

Sample program benchmark that just returns the text OK FastAPI started with gunicorn-> uvicorn x4

100 simultaneous

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 simultaneous

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 simultaneous

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

Fast API is good. .. ..

• For normal use, vertx and Fast API will be about the same speed. FastAPI shit fast
• FastAPI requires less source code, call immediately
• Performance is within the margin of error for practical use.

It seems to converge on the problem of preference of the language used rather than FW I like Vertx.

• The IDE detects mistakes in great detail before it works (static typing)
• You can work without worrying about the directory structure
• Easy to build project structure
• Vertx also has dreams such as eventbus

I'd like to defend Vertx with a position talk that has selected the technology, but I'm no longer complaining about the goodness of the Fast API. FastAPI will be popular. It's already popular. Vertx has always been a minor FW. ..

FastAPI

• Automatic real-time generation of API documentation
• Easy to reload in real time during development
• Impression that web articles are more fulfilling than vertx
• Overwhelmingly simple and easy to stick to
• It's easy to connect with AI (should it be?), So it seems that the backend can be completed with Python.
• Anyone can write the code with the same visibility → Super important
• It feels like it matches the recent trend of making the server side thin, light, and fast.
• If you use Docker, it seems easy to deploy.
• C10K okay
• It seems that session is not standard because it is API specialized. issue is standing

Vertx

• The fun of static typing (with Kotlin). It will point out typos even if it does not start
• Get the full benefits of the IDE. Complementation and refactoring feels like a long day with an IDE
• Easy to deploy using fat-jar (I like the fun of completing server construction with Java)
• (I) Kotlin is fun to write
• (Developed using the OpenAPI library) The API document will also be automatically generated.
• Best of OpenAPI loading → Important
• There are JVM assets such as logging (maybe this is just something I'm not familiar with Python, but log4j is useful)
• A dream called event bus
• C10K okay
• Actually, I have a lot of things and I feel like I don't need anything else. Since there is a session, it is easy to maintain authentication with a session cookie in the traditional way.
• If you want to do it, you can do DI by Spring. can do anything

Comparison with other frameworks

Since it is a JVM language and Python, it seems easier for engineers to collect than actix. For business use, iron plate Spring Boot or .Net MVC seems to be good because it has a lot of information.