Комментарии 39
Фронт есть какой удобный в связке?
/docs
Нет и не будет. FastAPI - это исключительно API, тоесть Backend.
Нужна связка Back+Front - это надо смотреть в сторону Django.
тоже интересно - есть ли генерируемые формы из спеки openapi?
можно генерить модели по спеке openapi
можно генерить клиенты по спеке openapi
можно генерить сервера по спеке openapi
можно генерить документацию по спеке openapi
можно генерить спеку openapi по моделям
когда уже можно будет генерировать формочки по спеке? чтобы и селфхост, и опенсорс, и контейнеры готовые - бери да в рот тащи
Ну и чем это лучше, чем Flask?
Интересный подход, только в чем фишка использования английских слов на русском? Сложно писать вместо "ендпойнт" - конечная точка, "валидации" - проверка целостности и тп? Текст от этого только читабельнее был бы. Научные от этого он точно не становится. А так - молодец)
Здравствуйте. Эти слова уже закрепились в профессиональном мире) Мы стараемся не отставать и писать на доступном языке. Кроме того, иногда они лучше подходят по контексту и смыслу. Например, валидация — это же не всегда проверка целостности. Спасибо за отзыв!
Мне кажется, слово "ручка" (видимо, handle или handler?), которое здесь есть, больше затемняет, чем проясняет.
А как же логирование... Куда копать, если приложение сломается... Билдить образ на прод сервере... Зачем git на проде... Зачем докер на VPS... Логичнее создать venv и закинуть код через scp.
Добрый день! Спасибо за замечания! В статье мы фокусировались на реализации простейшего API. Вы правы, что есть еще много аспектов разработки и деплоя, которые могут быть важными в реальном продакшн-окружении. Однако, как было сказано в заключении, демонстрация является фундаментом для построения более сложных приложений ?
Зачем докер на VPS
А в чем проблема то?
Проблема в том, что Докер это инструмент для решения определённых задач. Хорошо бы уточнить, какую именно проблему он решает здесь. Я не вижу ни одной причины его затаскивать. Виртуальный сервер, всего лишь полгига памяти, одно приложение, один процесс, привязки к версии Пайтона нету. Надо загрузить больше ядер - естественно будет добавить gunicorn. Мне неприятно, когда гвозди микроскопом забивают ;)
Докер дает совершенно минимальный оверхэд по памяти. По сути это обвязка над ядерными cgroups/namespaces. Точно так же можно сделать изоляцию с помощью systemd и iptables, но потратив на это чуть больше времени и нервов. Ну или взять lxc - суть не меняется. Плюсом тут изоляция от хоста (в том числе и то, что не нужно на хост тащить питон и все нужные причендалы).
Я не про оверхед, а про то что ресурс уже ограничен на нижнем уровне и выделен целиком под приложение. Зачем изолироваться от «хоста» который в данном случае уже виртуалка? Не тащить Пайтон на уровень Убунты, но затащить его же уровнем выше внутри Дебиан-контейнера? Я не против Докера, сам применяю и знаю устройство. Вопрос/просьба в другом - может не надо пожалуйста новичкам давать ложное убеждение, будто без Докера приложение не развернуть.
Зачем
Потому что это удобно. Одинаковое окружение приложения на любом сервере, разворачивается одной командой.
Насчет изоляции еще - приложений может быть далеко не одно на одном сервере. Зачем разворачивать целую виртмашину с операционкой ради одного приложения, которому нужна максимум сотня метров оперативы. Ну и плюс еще docker swarm, k8s и вот это вот все.
может не надо пожалуйста новичкам давать ложное убеждение, будто без Докера приложение не развернуть
Так вроде никто и не дает. Ну и я бы не сказал что статья для совсем новичков.
Насчет изоляции еще - приложений может быть далеко не одно на одном сервере. Зачем разворачивать целую виртмашину с операционкой ради одного приложения, которому нужна максимум сотня метров оперативы. Ну и плюс еще docker swarm, k8s и вот это вот все.
Давайте не уходить от темы статьи и читать внимательно условия задачи. Ещё раз - автор статьи сам выбрал виртуальный сервер, полгига рамы. Под одно это единственное приложение. Один сервер, других нет в плане. Ни слова не сказал про утилизацию ресурсов, запустил в 1 поток. Всё. Вы зачем-то нафантазировали другие приложения и кубернетисы.
Давайте начнем с того, что вся эта ветка началась с вашей фразы "Зачем докер на VPS". Я ответил зачем. Что там и зачем выбирал автор в сабже это его дело (а т.к. статья в корп. блоге, то все в принципе понятно).
Если же ваше возражение было на тему "зачем тут докер вообще", то так и стоило бы написать.
Гм. Наверное по тому, что в жизни оно в 9 случаях из 10 будет деплоиться в виде контейнера (под управлением оркестратора), а 1 оставшийся хорошо бы обходить стороной-стороной да побыстрее, не? Доскер в наше время не "средство изоляции", а platform-independant средство доставки. Да, в убунту тоже можно поставить софт через make && make install && make clean - но "не давать новичкам ложное впечатление, что без пакетного менеджера приложение не развернуть" как-то даже и странно :).
Предполагаю, что реальные кейсы, где OCI-compilant контейнеры как "средство доставки" действительно не нужны и их НЕ использование - осознанный выбор команды действительно существуют - но этим ребятам "туториал" предполагаю что и не нужен - они знают что и зачем делают.
в жизни оно в 9 случаях из 10 будет деплоиться в виде контейнера (под управлением оркестратора)
Статья то не об этом. Выше публикатор отметил, что эта демонстрация является фундаментом... Вы предлагаете MVP из двух ручек без мониторинга и авторизации сразу на кластер деплоить? Бухгалтерия одобряет ;)
в убунту тоже можно поставить софт через make && make install && make clean - но "не давать новичкам ложное впечатление, что без пакетного менеджера приложение не развернуть" как-то даже и странно :).
Господи боже мой, вы о чём? В Убунте Питон вроде бы искаропки уже есть. А если нет - make install не обязателен, потому как там ровно такой же apt-get install как и внутри python:3.11-slim из статьи.
Доскер в наше время не "средство изоляции", а platform-independant средство доставки.
Т.е. доставка в этой статье вас не смущает? Билд прямо на проде и руками, жирный образ без мультистейджа, запуск под рутом;)
В статье меня смущает примерно "все", о чем я написал отдельным комментом. Просто коллекция плохих практик и дурных советов by Григорий Остер от ИТ.
Но вот конкретно рекомендация по деплою контейнером (Не "реализация", а метод) - кмк для туториала разумная.
Господи боже мой, вы о чём?
"А" - аналогия.
Так выглядит «ручка» GET /tasks:
what is "ручка" ?
А подскажите, почему в TasksReposiotory смешиваются два стиля, добавление идет через метод add объекта сессии, а извлечение данных через exequte и запрос select, можно же было добавлять через insert.
Или в этом может есть какой-то смысл, и подобное смешение оправдано?
Что мне НЕ нравится в подобного рода туториалах - (неявное) тиражирование плохих практик. "Как БЫСТРО написать" - и в продакшун!
Где вменяемая структура проекта? В Ревде. Где комментарии в коде? В Салде. Где логгирование? В Барде. Где минимальный cli\config для запуска? В Куеде. Где обработка хоть одного исключения? В Тавде. Где... в общем, много еще русских городов есть, ага.
Управление зависимостями через приколоченные в requirenments.txt версии в 2024 году? O'rly? А зачем в нем click==8.1.7, который в проекте не используется? Ну, у автора "так получилось".
И добро бы это было что-то сложное, "со звездочкой", "для продвинутых" - кому надо всё это сами знают и умеют, но тут-то ту-то-ри-ал - кто-то вот эту вот каку обязательно в рот и потащит, а потом "у питонистов каквсигда".
Нинада так. Пожалуйста.
Пырастите, я человек незнающий, а в чём проблема с "Управление зависимостями через приколоченные в requirenments.txt версии в 2024 году? O'rly?" ?
https://quanttype.net/posts/2023-10-31-do-not-use-requirements.txt.html
TL;DR: requirements.txt это обычный дамп всех зависимостей, нормально контролировать зависимости через него невозможно. Попробуй установить какой-нибудь старый проект. Скорее всего ничего не получится.
(сам https://github.com/huyhoang17/kuzushiji_recognition пытался запустить и куча wheel/cython ошибок, в итоге сам зависимости прописал и запустилось)
Эмм... ну, примерно в том, что он не очень хорошо позволяет "управлять зависимостями"/"управлять проектом" же, и не слишком подходит для решения остальной пачки задач, нет?
Для туториала я бы сразу писал про poetry, скорее всего.
в Катманде
Простите но меня резануло использование classmethod как staticmethod, нут так и надо было объявить их как staticmethod.
Статья противопоказана для новичков.
Sqlite, глобалы, "паттерн репозиторий" (лол) на классметодах. Это попытка заменить уже существующий официальный, и также далеко не идеальный, туториал FastAPI из документации? Плохая попытка. Новички прочитают эту статью, научатся неправильным вещам, и будут потом писать также неправильно. Для прошаренных статья также бесполезна, так на кого она рассчитана?
А с sqlite-то что не так? Я понимаю, к sqlalchemy претензии - оно и впрямь разрослося преизряднейшим образом, но sqlite для задачи выглядит прям идеальным вариантом.
Для SQLite нет места в вебе, он нужен для однопользовательских приложений (десктопные программы или мобильные приложения, например), а для многопользовательских нужно брать что-то по-серьезнее, например, PostgreSQL или MySQL/MariaDB.
Вангую аргументы по типу «для примера сойдет», «когда пользователей немного - самое оно», поэтому сразу привожу контраргументы:
1. Для примера не сойдет, поскольку эта статья, судя по всему, рассчитана на новичков, которые будут брать эту СУБД в каждый свой проект, зачем учить людей "бэд прэктисам"? Ничего не стоит показать подключение к более подходящей к этой задаче СУБД. К тому же, зачем учиться на SQLite, когда можно сразу учиться на нормальной клиент-серверной СУБД? Зачем учиться на SQLite, если бекенд-разработчик все равно не будет его использовать на работе? Порог входа не то чтобы прям сильно выше, чтобы выбор пал на SQLite.
2. SQLite конечно будет работать и когда пользователей не мало, но что стоит запустить тот же Постгрес? Я понимаю, если бы это было платно, но нет же, да и с докером (для тех же "учебных целей") это делается одной командой, да даже без докера это делается минут за 5. "В подарок" мы получаем большое количество фич и преимуществ, которые в SQLite недоступны.
Так что нет, это не выглядит "прям идеальным вариантом".
Для SQLite нет места в вебе, он нужен для однопользовательских приложений (десктопные программы или мобильные приложения, например), а для многопользовательских нужно брать что-то по-серьезнее, например, PostgreSQL или MySQL/MariaDB.
Интересный вопрос, ответ на который как по мне - не очевиден. Начать с того, что на задачах, в том числе условно "многопользовательских", не требующих для решения горизонтального масштабирования бэка sqlite тупо быстрее имеющихся альтернатив. В случае с nosql можно конечно еще быстрее найти - делов-то, но именно с SQL - так. А класс задач "веб-интерфейс под 0,0-хрен сколько RPS" если что - нифига не узкий, процентов 40 in-source разработки корп. софта туда в общем-то влезет. Нууууееееэээсли у вас готовая инфра уровня предприятия уже отстроена - то скорее всего проще под нее подстроиться - но и то, не факт.
Для примера не сойдет, поскольку эта статья, судя по всему, рассчитана на новичков, которые будут брать эту СУБД в каждый свой проект, зачем учить людей "бэд прэктисам"?
Во времена моей иуности так говорили про interbase\firebird - мол, для себя пиши на ём, оно максимум ANSI-compilant, на прод со сменой БД перенесешь почти без изменений - нуууу... иногда оно как-то вот так и выходило. Более того, иногда оно на ём в прод и шло :). Сейчас примерно то же можно сказать про SQLITE, особенно при работе с ним через ORM. Более того, даже в достаточно сложных случаях - переход SQLITE->postgres или SQLITE->mysql "в среднем" проще, чем например postgres->mysql.
К тому же, зачем учиться на SQLite, когда можно сразу учиться на нормальной клиент-серверной СУБД? Зачем учиться на SQLite, если бекенд-разработчик все равно не будет его использовать на работе? Порог входа не то чтобы прям сильно выше, чтобы выбор пал на SQLite.
На том, что осмысленно делать через ORM - практически монопенисуально же. А если уж возникла необходимость лабать бизнес-логику server-side (что опять же антипаттерн в наше время) или там специфически оптимизировать производительность - то туториал вам точно не нужен и проблемы у вас будут нифига не с "подключением к БД".
SQLite конечно будет работать и когда пользователей не мало, но что стоит запустить тот же Постгрес?
Воу. Вот тут скорее не согласен - это даже не "тяпляпсерский", а "кодерский" подход - мол, если "запустить пять минут" - то "тратим пять минут - и запускаем", а дальше любись оно единорогом, я свое дело сделаль! Эксплуатационная сложность рСУБД достаточно высокая штука, то, что оно у тебя в "дефолтах работает" - не означает, что работает хорошо и безопасно. В плане "поставил и забыл" sqlite сильно более дешевая вещь с нулевыми накладными расходами на maintenance и минимальной attack surface.
Автору следует прочитать, что такое паттерн "репозиторий" из книги
"Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура"
А зачем вообще нужен какой-то туториал, если всё написано на официальном сайте фастапи?
Как быстро написать API на FastAPI с валидацией и базой данных