Декларативность и императивность веб-фреймворков: где крайности, истина посередине?

Такие конструкции и концепты языка python как глобальные переменные, декораторы и аннотации типов вместе с интерпретируемостью и инструментами рефлексии позволяют создателям фреймворков включать в него различные способы определения каркаса web-сервиса. Популярный FastAPI и уже зрелый Flask тяготеют к декларативности.

Роутинг, валидация, документация и инициализация приложения завязаны на модификацию view-функций с помощью декораторов и аннотаций. С такого подхода стартуют многие проекты, однако так ли он хорош в приложениях с десятками эндпоинтов, которые содержат средства для аутентификации, документирования, поддержания обратной совместимости, разграничения областей видимости и пр.?

При разрастании кодовой базы приложения, составленного при помощи аннотаций и декораторов, возможны следующие трудности: конфликты внешних зависимостей, сложности тестировании приложения, где необходимы кастомные подключения к внешним зависимостям или эмулирование аутентификации.

В докладе выделим преимущества и недостатки декларативного и императивного подхода в определении скелета web-сервиса. Сопоставив их с масштабами приложений и обсудим, в каких моментах будет выгодно отойти от идиоматического подхода фреймворка. Также, на примере Flask и FastAPI покажем, как извлекать преимущества из обоих стилей, для этого посмотрим исходный код фреймворков и решения, принятые их создателями.