Чи мертвий Flask? Чи є FastAPI майбутнім? - javascript.org.ua

Під час своїх відповідних пошуків я помітив, що навіть у 2024 році чимало людей все ще рекомендують Flask як фреймворк для веб-розробки на Python. Однак на мою думку, “Flask виходить на другий план, а FastAPI — це майбутнє”. Ось чому я пишу цю статтю. Запрошую всіх долучитися до обговорення та запропонувати контраргументи.

Flask проти FastAPI

Flask займає значне місце в серцях розробників Python. Якщо ви веб-розробник, я впевнений, що ви, ймовірно, використовували Flask, але, можливо, ніколи не стикалися з FastAPI.

Ось два факти:

У нових значущих проектах на Python, пов'язаних з веб-розробкою, за останні один-два роки майже всі проекти, що стосуються веб-розробки, вибрали FastAPI.
2.

Станом на 25 грудня 2024 року на GitHub кількість зірок у FastAPI (78.9k) вже перевищила кількість зірок у Flask (68.4k).

Тепер давайте подивимося на зміни в пропорціях веб-фреймворків у офіційних опитуваннях розробників Python:

Очевидно, що у 2019 році FastAPI навіть не було у списку варіантів, але до 2023 року його частка досягла 25%. (Наразі ми маємо лише дані до 2023 року.)

Слід зазначити, що ці дані про пропорції охоплюють існуючі системи, тому частки Django і Flask не знизяться різко. Однак тренд очевидний.

Ми всі знаємо, що сфера веб-фреймворків є надзвичайно продуктивною, з новими фреймворками, що з'являються майже щороку. Більшість з цих фреймворків мають коротке життя, хоча деякі з них встигають витримати випробування часом. FastAPI з'явився наприкінці 2018 року і почав заробляти популярність наприкінці 2019 року.

Отже, як він зміг обігнати Flask, який з'явився наприкінці 2010 року, за популярністю всього за п'ять років? Далі давайте простежимо історію розвитку веб-фреймворків для Python та пов'язаних рішень за допомогою хронології для кращого розуміння.

Еволюція веб-фреймворків (плагіни, інструменти)

Автором FastAPI є розробник, який надзвичайно уважно стежить за розвитком екосистеми Python. Розширене посилання для читання 2 — це “Alternatives, Inspiration and Comparisons”, написане автором (https://fastapi.tiangolo.com/alternatives/), яке детально розглядає посилання або натхнення, які FastAPI черпав з різних бібліотек. Розділ історії розвитку цієї статті також посилається на цей матеріал.

Рекомендую прочитати оригінальний текст, оскільки він містить обґрунтування виникнення FastAPI, а також деякі концепції дизайну автора.

Flask

Flask — це “мікрофреймворк”, що кардинально відрізняється від Django. Він зберігає лише кілька основних функцій і, щоб розділити обов'язки, розподіляє інші функції на кілька бібліотек (наприклад, Jinja2, Werkzeug тощо). Це дає розробникам велику свободу і дозволяє легко писати сторонні плагіни для пов'язаних функцій. Його внутрішні конструкції, такі як шаблони, контексти та декоратори для представлення маршрутів, сигналів тощо, були досить передовими на той час. Разом з детальною документацією, Flask є надзвичайно дружнім до новачків.

Flask REST фреймворки

Завдяки своїй простоті, Flask чудово підходить для побудови API. Однак, оскільки сам Flask не має вбудованих функцій, нам потрібні спеціалізовані REST фреймворки.

Внаслідок цього з'явилися фреймворки, такі як flask-restful, Flask-RESTPlus та flask-api. Крім того, у REST-сервісах виникають вимоги до валідації даних, парсингу та специфікацій, що призвело до появи Marshmallow, Webargs та APISpec, поки не з'явився Flask-apispec. Проте, протягом цього процесу розвитку, фреймворк для Flask, який би можна було порівняти з DRF, так і не з'явився.

На цьому етапі недоліки Flask поступово вийшли на перший план.

Початкові переваги Flask полягають у його гнучкості та мінімалізмі, але це також означає, що значну кількість компонентів необхідно розробляти самостійно. Це вимагає або великої компанії з виділеними розробниками для розробки та підтримки, або надзвичайно здібних індивідуальних розробників. В іншому випадку, важко забезпечити високий рівень якості плагінів, що призводить до змішаного набору сторонніх плагінів для Flask, без гарантії їх довгострокової підтримки.

Як вже згадувалося раніше, багато з цих бібліотек вже припинили своє оновлення.

Отже, навіть сьогодні, якщо ви хочете створити API-сервіс за допомогою Flask, вам все одно доведеться збирати різні компоненти. Для деяких компонентів, які не оновлюються своєчасно, вам доведеться вирішувати проблеми самостійно. Для ветеранів це може бути посильним завданням, але для початківців це досить лякаюче, особливо коли вони хочуть застосовувати останні практики та концепції.

Екосистема Asyncio

З версії Python 3.5 asyncio став майбутнім трендом. У результаті з’явилися веб-фреймворки, які нативно підтримують asyncio, такі як aiohttp, Starlette та sanic.

У цей час Flask був неохоче адаптуватися.

Спільнота повільно додавала підтримку для asyncio, а оригінальний автор Flask перейшов до написання на Rust, залишивши проект у руках двох мейнтейнерів (тепер залишився лише один).

Проекти для створення API-сервісів, такі як apistar і molten, стали джерелом натхнення для створення FastAPI.

FastAPI

Тоді з'явився FastAPI. Автор спочатку шукав хороше рішення, але вищезгадані ситуації мали свої проблеми або обмеження. Тому автор створив цей новий фреймворк.

Чому FastAPI виділяється

Це основна частина статті. Ось чому FastAPI може замінити Flask.

Валідація даних користувача з Pydantic

У процесі розробки API валідація формату даних, парсинг і серіалізація є рутинними операціями.

За роки з’явилося багато рішень, і наразі Pydantic є найбільш популярним вибором:

from fastapi import FastAPI  
from pydantic import BaseModel

class Item(BaseModel):  
 name: str  
 description: str | None = None  
 price: float  
 tax: float | None = None  
app = FastAPI()  
@app.post("/items/")  
async def create_item(item: Item):  
 return item

На перший погляд цей код може здатися способом написання ORM або dataclass, але насправді він використовує нативний синтаксис Python для Type Hints для анотації типів полів. Наприклад, у наведеному прикладі схема Item для запиту /items/ чітко визначена, і типи значень кожного поля явні. Порівняно з старими методами використання описів схем або навіть хардкодингу, цей підхід є більш лаконічним, краще відповідає стилю Python і має кращу підтримку в IDE.

Наразі Pydantic домінує у галузі валідації даних користувача.

Оскільки FastAPI має це вбудованим, процес валідації значно спрощений, а помилки знижуються. Ось чому на офіційному сайті FastAPI згадується, що це рішення може зменшити кількість помилок розробників до 40%. Для динамічної мови, такої як Python, використання Pydantic є необхідним, якщо ви не використовуєте mypy для перевірки типів.

Більше того, завдяки інтеграції Pydantic, додавання ORM (такого як SQLAlchemy) в проект стає надзвичайно простим. Об'єкти, отримані з запитів, можуть бути безпосередньо передані в базу даних, оскільки валідація даних вже завершена. І навпаки, об'єкти, отримані з бази даних, також можна безпосередньо повернути.

На відміну від цього, Flask у цьому відношенні має обмеження.

Асинхронний дизайн

В еру Flask виконання коду було однонитковим та синхронним. Це означало, що запити мали оброблятися один за одним, і інші запити витрачали час, чекаючи на операції вводу/виводу, поки не завершиться попередній.

Asyncio, з іншого боку, є оптимальним рішенням. Він дозволяє зробити операції вводу/виводу асинхронними, даючи змогу отримати результати завдань без очікування на їх завершення, а потім перейти до обробки інших запитів.

FastAPI нативно підтримує одночасний та асинхронний код. Якщо код написано правильно, він може досягати максимальної ефективності. Тому FastAPI вважається найшвидшим фреймворком для Python на даний момент, з ефективністю, подібною до NodeJS або Go. Коли важливі швидкість і продуктивність, FastAPI безсумнівно є найкращим вибором.

Нативна підтримка ASGI

Почнемо з WSGI. Повна назва — “Python Web Server Gateway Interface”, що описано в “PEP 3333” (https://peps.python.org/pep-3333/). Це стандарт Python, написаний спеціально для взаємодії між веб-додатками та серверами. Якщо ви використовували PHP або Ruby, вам може бути легше це зрозуміти.

Flask залежить від Werkzeug, який є набором WSGI, тому Flask підтримує цей старий стандарт WSGI, а не ASGI.

Проблема з WSGI полягає в тому, що він не може використовувати асинхронність для покращення продуктивності та ефективності. Тому Django Channel став піонером ASGI. Повна назва — “Asynchronous Server Gateway Interface”, що є ітеративним і майже повністю переписаним стандартом. Він забезпечує асинхронні серверні/додаткові інтерфейси та підтримує HTTP, HTTP/2 і WebSocket. На відміну від WSGI, ASGI дозволяє кожному додатку мати кілька асинхронних подій. Крім того, ASGI підтримує як синхронні, так і асинхронні додатки. Ви можете або мігрувати старі синхронні веб-додатки WSGI до ASGI, або використовувати ASGI для створення нових асинхронних веб-додатків.

Перед тим, як зробити висновки, давайте додамо п’ять пояснень термінів:

ASGI Toolkit: Бібліотеки, які реалізують функції, пов'язані з ASGI (такі як маршрутизація URL, об'єкти запитів/відповідей, шаблонні движки тощо).

У цій статті в основному йдеться про Starlette, яка відповідає за залежність Flask — Werkzeug.
2. ASGI Web Framework: Веб-фреймворки, що реалізують специфікацію ASGI (такі як FastAPI), тоді як Flask і Django є веб-фреймворками, що реалізують WSGI. Ці фреймворки призначені для того, щоб розробники могли писати додатки з простими у використанні інтерфейсами. Розробникам потрібно лише заповнити бізнес-логіку відповідно до своїх потреб. Ранні фреймворки переважно реалізовували ASGI-інструменти всередині, тоді як пізніші фреймворки зазвичай комбінують відповідні інструменти. Наприклад, Flask використовує Werkzeug (свій власний), а FastAPI використовує Starlette (від інших).
3. Web Application: Додаток, створений за допомогою веб-фреймворку, є веб-додатком. Зазвичай веб-фреймворки постачаються з тестовим сервером, який можна запустити для розробки та налагодження.

Якщо продуктивність і стабільність не є важливими, ви вже можете отримати доступ до адреси розробки в браузері, щоб відвідати цей додаток.
4. Web Server: Реальний світ складніший, ніж очікувалося. Після того, як веб-додаток буде розгорнутий у виробничому середовищі, потрібно враховувати такі вимоги, як балансування навантаження запитів, обслуговування статичних файлів, контроль доступу та зворотний проксі, а також високі вимоги до продуктивності. Вбудовані веб-сервери веб-фреймворків не можуть задовольнити ці вимоги, тому потрібні спеціалізовані веб-сервери. Наразі Nginx є основним вибором.
5. ASGI Server: ASGI сервер виконує роль моста між веб-сервером та веб-додатком. ASGI сервер також дотримується специфікації ASGI, але його основне завдання — відповідати вимогам продуктивності для переадресації запитів, тому він в основному займається частиною “G” (gateway) ASGI. Його код не дуже зручний для розробників для написання бізнес-логіки веб-додатків і маршрутизації.

Наразі найбільш відомим ASGI сервером є Uvicorn, а uvicorn.workers.UvicornWorker, який спочатку походить від WSGI сервера Gunicorn, також є варіантом. Це рекомендоване використання в виробничому середовищі.

Раніше рішення для виробничого середовища для WSGI зазвичай було Nginx + Gunicorn + Flask(Django), тоді як зараз рішення для виробничого середовища для ASGI — це Nginx + Uvicorn + FastAPI.

Ще одна річ. Оцінивши назву та введення FastAPI, очевидно, що він призначений для створення API-сервісів. Насправді, його основний код саме такий. Можна сказати, що це не традиційний, повністю самостійно реалізований фреймворк, а скоріше фреймворк, який поєднує сильні сторони різних фреймворків. Починаючи з порожньої оболонки, він збирає необхідні та підходящі компоненти. Наприклад, у нього немає шаблонного движка.

Якщо вам дійсно потрібно використовувати це для створення веб-додатка, який потребує рендерингу шаблонів, ви можете вибрати та комбінувати шаблонний движок, який вам потрібен. Звісно, ви також можете використовувати Jinja2, вбудований у Starlette (так, він також вбудований у Flask).

Чому кажуть, що Flask мертвий

Переваг FastAPI, згаданих вище, недостатньо для того, щоб стверджувати, що Flask мертвий. Отже, чому я дотримуюсь цієї думки? Все зводиться до популярності серед розробників і користувачів.

"Популярність" тут є скоріше суб'єктивною. Ось кілька показників, які я можу навести:

Активність спільноти(https://github.com/pallets/flask/issues): Візьмемо, наприклад, кількість проблем і pull-запитів проекту. Flask має лише одноцифрові числа, що зовсім не йде в порівняння з FastAPI. Це насправді відображає, що проект більше не активний. Якщо проект активний, старі користувачі матимуть більше потреб.
Зупинка запитів: Якщо вони перестають ставити питання, це означає, що вони пішли. А нові користувачі обов’язково матимуть усілякі проблеми. Навіть за наявності детальної документації все одно повинно бути багато користувачів, які приходять ставити питання і вносити свій код. Відсутність таких ситуацій вказує на меншу кількість користувачів.
Популярність обговорень: Це популярність запитів і обговорень на блогах, Stack Overflow та інших сайтах. Очевидно, що останнім часом дуже мало людей пишуть про Flask.
Частота ітерацій розвитку(https://github.com/pallets/flask/pulls): Якщо подивитися на записи комітів, можна побачити, що у Flask лише один утримувач, який час від часу виправляє деякі баги, але без суттєвого розвитку нових функцій.
Вплив ключової фігури: Ключова фігура, яка стояла за Flask, ініціатор проекту, давно припинила участь у проекті.

Згідно з записами про внесок у проект, Армін Роначер останній раз вніс зміни до розвитку шість років тому.

Всі ці ситуації, на мою думку, свідчать про те, що час розквіту Flask минув, а FastAPI — це зірка, що зростає.

Наприкінці хочу представити ідеальну платформу для розгортання Flask/FastAPI: Leapcell.

Leapcell — це хмарна платформа для обчислень, розроблена спеціально для сучасних розподілених додатків. Модель ціноутворення «плати за використання» гарантує відсутність витрат на простої, що означає, що користувачі платять тільки за ресурси, які вони реально використовують.

Унікальні переваги Leapcell для WSGI/ASGI додатків:

1. Підтримка кількох мов програмування

Підтримує розробку на JavaScript, Python, Go чи Rust.

2. Безкоштовне розгортання необмеженої кількості проектів

Плата стягується лише за використання. Без плати, коли немає запитів.

Невідповідність вартості та ефективності

Плати за використання, без зборів за простої.
Наприклад, $25 може підтримати 6,94 мільйона запитів з середнім часом відповіді 60 мілісекунд.

4. Спрощений досвід розробника

Інтуїтивно зрозумілий інтерфейс для легкого налаштування.
Повністю автоматизовані CI/CD пайплайни та інтеграція GitOps.
Метрики та логи в реальному часі, що надають практичні інсайти.

5. Легкість масштабування та висока продуктивність

Автоматичне масштабування для легкого оброблення високої кількості одночасних запитів.
Відсутність накладних витрат на операції, що дозволяє розробникам зосередитись на розробці.

Дізнайтесь більше в документації!

Leapcell Twitter: https://x.com/LeapcellHQ

Перекладено з: Is Flask Dead? Is FastAPI the Future?