Войти через соцсеть:
Войти через email:
Backend, а в прошлом - fullstack, разработчик, интересуюсь анализом и переносом концептов, подходов и паттернов из одних языков программирования в другие на благо чистоты кода и поддерживаемости приложения.
Такие конструкции и концепты языка python как глобальные переменные, декораторы и аннотации типов вместе с интерпретируемостью и инструментами рефлексии позволяют создателям фреймворков включать в него различные способы определения каркаса web-сервиса. Популярный FastAPI и уже зрелый Flask тяготеют к декларативности.
Роутинг, валидация, документация и инициализация приложения завязаны на модификацию view-функций с помощью декораторов и аннотаций. С такого подхода стартуют многие проекты, однако так ли он хорош в приложениях с десятками эндпоинтов, которые содержат средства для аутентификации, документирования, поддержания обратной совместимости, разграничения областей видимости и пр.?
При разрастании кодовой базы приложения, составленного при помощи аннотаций и декораторов, возможны следующие трудности: конфликты внешних зависимостей, сложности тестировании приложения, где необходимы кастомные подключения к внешним зависимостям или эмулирование аутентификации.
В докладе выделим преимущества и недостатки декларативного и императивного подхода в определении скелета web-сервиса. Сопоставив их с масштабами приложений и обсудим, в каких моментах будет выгодно отойти от идиоматического подхода фреймворка. Также, на примере Flask и FastAPI покажем, как извлекать преимущества из обоих стилей, для этого посмотрим исходный код фреймворков и решения, принятые их создателями.