О кілька років тому моя команда була відповідальна за підтримку середнього розміру Flask-додатка, який підтримував наш бек-офіс. Як і багато Python-розробників того часу, я чув про FlaskAPI і став зацікавлений ним. Прочитавши їх чудову документацію і експериментуючи з ним на побічному проекті, я зрозумів дві речі: я більше не хочу писати кінцеві точки іншим способом, а FastAPI не є точним замінником Flask.
По-перше, є багато хороших причин вибрати FastAPI як фреймворк. Але для мене те, що найбільше виділяється, це його естетика: мінімалістичний спосіб, яким він дозволяє здійснювати складний розбір запитів та серіалізацію відповідей, по черзі додаючи типи. Це дозволяє значно скоротити частину коду і дозволяє фреймворку обробляти це більш ефективно, ніж ви б це зробили. Є краса в його простоті, і я вважаю, що це достатня причина, щоб розглянути FastAPI. Адже за економією коду ховається як вдосконалення фреймворку, так і краща підтримка вашого додатка.
По-друге, хоча перший погляд на FastAPI може дати вам враження, що це клон Flask з "стероїдами", це не так. І хоча відмінності можна подолати, вони вимагають деяких налаштувань. Наприклад, трасування помилок (tracebacks) досить відрізняється, що робить відладку FastAPI-додатка відчутно іншим досвідом для тих, хто звик до Flask. Також залежність FastAPI для впровадження ін’єкцій залежностей контрастує з використанням Flask глобальних об’єктів для доступу до бази даних, наприклад. Це залежить від смаку і звичок, і це не є критичним недоліком. Однак, при міграції кінцевих точок одну за одною, поєднання двох фреймворків може створити певні витрати на переключення, і це все має бути варте ваших зусиль.
Погана новина для мене полягала в тому, що в моєму контексті міграція не виправдала зусиль, і я опинився між молотом і наковальнею: залишитися на написанні шаблонного коду, який я почав ненавидіти, або просувати міграцію фреймворку, яка не мала сенсу. Що як я міг би отримати найкраще з двох світів — або ж фреймворків, і принести естетику FastAPI до мого Flask-додатка без його покидання?
Мені знадобилося трохи експериментів, але моя перша реалізація була надзвичайно простою — менше ніж 100 рядків коду. Це далеко не покривало всі функції FastAPI, але дозволило нам почати писати кінцеві точки в стилі FastAPI, і для мене цього було достатньо: ми могли насолоджуватися економією FastAPI без міграції жодної кінцевої точки, просто додаючи типи та рухаючись вперед.
Ця реалізація поступово еволюціонувала, повільно підлаштовуючись під наші потреби. В кінцевому підсумку, вона дозволила нам почати обслуговувати клієнтські, даноємні функції. У той же час вона залишалася мінімалістичною, основний принцип додавання типів як інструменту валідації даних був досить простим для реалізації. Як тільки цей шматок коду довів свою надійність, я вирішив спробувати опублікувати його у вигляді повноцінного пакету Python. Тут і почалась важка робота.
Частина з публікацією не була особливо складною, але поки ви її робите, краще зробити все правильно. Це вимагало налаштування інструментів автоматизації, посилення тестів і написання детальної документації, що займає багато часу. Я також повністю переписав код, щоб зробити його більш розширюваним і врахувати інші варіанти використання поза нашою початковою метою.
Це вимагало глибокого занурення у внутрішню роботу Flask і FastAPI, і було найцікавішою частиною шляху.
В кінці кінців я побудував свій перший повністю відкритий проект на стику двох моїх улюблених веб-фреймворків і отримав потужний інструмент, доступний однією командою pip install, щоб впровадити його в будь-який інший Flask проект, з яким мені доведеться працювати.
А як щодо вас? Як розробник Flask, чи змінив FastAPI ваш підхід до написання кінцевих точок? Чи у вас є інша естетика, яка підходить вам найкраще?
—
Якщо ви хочете перевірити репозиторій, він знаходиться на GitHub.
Документація розміщена на readthedocs.
Для сміливих — можете просто встановити за допомогою pip install flask-jeroboam і спробувати.
Перекладено з: Building flask-jeroboam: bringing a taste of FastAPI to Flask