Кто как использует python для создания API? Какая-то фигня получается...

Что за наркобред я тут прочёл?

Ну хз. Берёшь DRF и ничего не надо копипастить.

https://falcon.readthedocs.io/en/stable

https://github.com/tiangolo/fastapi

Что копипастят и откуда?

На практике можно брать готовые фреймворки типа django, где есть все «из коробки», а можно брать валидаторы и сериализаторы отдельными библиотеками (cerberus, marshmallow), совмещая их использование с чем-то типа flask/fastapi/falcon/whatever.

И в том, и в другом случае ничего копипастить не нужно.

при написании какого-либо веб-приложения принято

• отделить фронт от бэка
• гонять json через вебсокеты

https://github.com/zalando/connexion

Я нуб, не делал пока API (хотя предстоит). Но по поводу сайта «вообще»:

Пишу сейчас себе сайтик, тоже на фласке. Никаких дурных дупликаций нет. За основу-пример взял flask-user, но мне не понравилось, и я оттуда многое повычистил. Остались flask_login, flask_sqlalchemy, flask_wtf, flask_mail, cryptography - никакой копипасты.

Использую именно ORM, не sqlalchemy core.

Что, так все и копипастят???

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

FastAPI пробовал? Если да, то как, норм?

Я так понимаю, что «high performance» - это сильно сказано, т.к. это питон?

Они просто заявляют:

Very high performance, on par with NodeJS and Go (thanks to Starlette and Pydantic)

Как это вообще возможно, Go же явно шустрее, как минимум, потому что компилируемый?

В web backend вся шустрость упирается в правильную работу с сетью. Если не блокировать поток воркера при каждом запросе к бд, а переключаться на другой запрос, то можно добиться примерно одинаковой производительности на любом языке, ИМХО.

Потому что никого не интересует дроч на циферки. Если у тебя есть блокирующий запрос к БД - он заблокирует одинаково и гошный код, и питонячий, а миллисекунды разницы во времени обработки результатов этого запроса роли не играют.

Ничего не заблокирует, если юзать пул коннектов

Тормознутые сериалайзеры в DRF с тобой не согласны) Там сериализация сама по себе достаточно медленная, и оказывает влияние на производительность. Будь подобная сериализация не на питоне, то работало б ощутимо шустрее.

Мир программирования на питоне не сошелся на DRF.

Это просто пример того, что не все в веб упирается в сеть

Я считаю, что большая часть производительности теряется именно там.

Чем тебе пул коннектов поможет, если у тебя таблица залочена?

• отделить фронт от бека
• гонять protobuf через grpc

я делаю апи на сях (скоро и на крестах), на питоне очень мало разрабатывал, вэбня не зашла както.

так все и копипастят?

а ты точно питон используешь весь?

ps и присоединяюсь - морду от реализации отделяй

Пробовал. Всё честно. Но, чем больше кода на питоне, тем тормознутее, конечно, будет итоговый REST. ORM тоже играет роль, но, в целом я уже приводил пример из жизни: выдаёт у меня django в debug режиме 700 req/sec, с запросами в бд, со всеми кишками, rest, и с шаблонизатором jinja, плюс никакого кеширования. Так вот, 700 req/sec на одно ядро, итого в минуту 40.000 клиентов грубо говоря, это 2.5 млн посетителей в час. На одной машине одноядерной выдерживает только в путь. Django. В debug режиме. Я ещё с такими проектами не сталкивался, которые бы упирались в такой req/sec на ядро. Да, всякие node.js + express (и аналоги) на современном железе и 5-7 тыс req/sec выдержат на ядро, не без этого, но это уже сумасшедшая производительность, которая нафиг не впёрлась чаще всего, Go выдаст под 9.000 req/sec на простых rest на такой виртуалке, где Django = 700 r/s

Если захотеть отмасштабироваться с Django - это не проблема, так что те же 9000 req/sec выжать можно на 3 виртуалках: 2 под бекенд, каждая по 4-8 ядра, и одна под бд в той же сети.

Есть две вещи которые вызывают у меня идиосинкразию - регулярки и протобуф.

Это не только к вебу относится.
Любые сортировки, вычисления и прочий матан, если его писали не рукожопые мамкины пограмисты, на питоне работает почти с такой же скоростью как и на ассемблере.
Потому что все матан-библиотеки всё-равно или на C или на плюсах написаны и производительность упрётся или в контроллер памяти или в IO в большнитсве случаев.
А на те операции, где она никуда не упирается, всё-равно уходит в худшем случае пара секунд в день. И можно их не считать.

Ты считаешь неправильно, в правильно собранном вебе производительность упирается в IO

Чини матан, 700 r/s это не «2.5 млн посетителей в час», это 2520000 r/s.
А сколько там посетитель сделает реквестов — вопрос конкретного проекта, но если это не какой-нибудь спам, который закрывают в первую же секунду, то явно больше.

9000 r/s го выдерживает на синтетике, в реальных ситуациях масштабировать в первую очередь придётся базу данных.

Даже не знаю. Когда руками перекладывал джейсончики - руки чаще тряслись.

ORM тоже играет роль

Для питоновской асинхронщины, кстати, есть ОРМ? Алхимия, как я понял, не катит?

700 req/sec с запросами в бд

Это довольно дофига для Джанги, особенно с запросами в бд и особенно без кеша. Чем замерял и как? ab?

В таком случае - ничем)

Что за наркобред я тут прочёл?

Проходите дальше, тут вам ничего интересного.

Спасибо.
Я вместо fastapi влез в flask_restx.
В FastAPI я немного не понял: вот есть у меня в ORM модель. Я без костылей введь не могу её в схему API отмапить, указав только список полей? Т.е. опять копипаст описания типов? Или я не туда смотрел?

Что копипастят и откуда?

Список полей/свойств с указанием типа.

Например, marshmallow требует описания того, что куда преобразовывать для каждого объекта. И вот эти описания я УЖЕ сделал в моделях данных и не хочу снова писать эту простыню. Потом то же самое в Flask-WTF (или Flask-Triangle).

Пробовал Flask-Potion, оно кажется умирает и сильно заморочено.

Прежде чем гонять json, его надо сформулировать. Тема об этом.

Хорошо. Были ли какие-нибудь идеи автоматически по моделям ORM создать формы WTF?

а ты точно питон используешь весь?

Вот это и хочу уточнить.

Видимо, да. Дорос до джанги.

Класс, но, видимо, не то. Я пляшу от структуры-модели данных, а это API без интеграции с данными, которую в нём писать самому.

Были ли какие-нибудь идеи автоматически по моделям ORM создать формы WTF?

Не понял вопрос, что значит «автоматически»? Ну скажем класс User, для него ведь могут быть разные формы – регистрация, смена пароля, и пр. Кмк, все формы надо всегда руками писать, индивидуально. И это не дупликация (и тем более не копипаста).

Я вместо fastapi влез в flask_restx

А что специалисты скажут, разве todo = api.model(... (Flask-RESTX гитхаб) - это большая дупликация с описанием модели ORM?

Он имел ввиду видимо что экземпляр класса User для конкретного пользователя должен содержать необходимые данные для видов форм, элементов и поведения. Ведь Грида она и в Африке грида, почему она должна быть другой например у класса Product… И т.д.

Shadow ты про это?

Ты лучше falcon юзай. Попробуй на прототипе, сваргань за вечерок. Я только для rest служб использовал, никакие формы не клепал вручную из python моделей, такая херня есть в django forms, у меня всё на vue/preact/прочем дерьме, которое на js моделях, стейте и всяких хуюках

никакие формы не клепал вручную из python моделей

Ну, формы в широком смысле - хоть angular модели, например...
Спасибо, посмотрю.

Можно например один раз описать класс FormGrid, которая будет в себя включать все необходимые элементы тулбары кнопки гриду. Клиент получая структуру User для своего уровня доступа автоматически формирует форму которая содержит только те элементы которые доступны для этого клиента. Или например один раз описать класс Item для редактирования деталей этой гриды.

Нет, немного не так.
Экземпляр класса User содержит данные, а по мета-данным класса валидатор должен сам решить, что и как ему валидировать, сериалайзер - как сериализировать, а шаблонизатор/препроцессор для фронтенда - как десериализировать и как обращаться к API.
Как тыт написали, DRF это делает.

Я ангуляр для форм использую - и все кнопки у меня в шаблонах. Тут вопрос, ЧЕМ и КАК эти кнопки наполнять.

Graphql/Appolo посмотри, может, это частично решает твои хотелки для привязки к Python http api

Есть Tortoise ORM, убожество, которое все поведшиеся бедолаги уже ненавидят. Есть, вроде как, приличный async-peewee для альтернативно-одарённых фанатов peewee.

Поверх алхимии есть Gino, это вполне приличное китайское поделие, но с некоторыми ограничениями относительно дефолтной алхимии. Юзаю уже год, полёт нормальный. Есть ещё вариант с sqlalchemy core и aiopg, но это просто генерация запросов с помощью моделей и вообще мерзость.

То есть по факту особо нормального варианта-то и нет? В чем профит тогда юзать вообще это все, если можно взять Go - трудозатраты будут ровно такими же, но будет строгая типизация, выше производительность и меньшее потребление памяти?

P.s. я не фанат Go, просто интересно, ведь получается, что у питона нет в данном случае преимуществ. Или есть?

Upd: хотя понял, почему на Go запарно API писать. У того же gin/gonic до сих пор, судя по всему, валидатор не может отдавать название поля, в котором ошибка)))

Gino более чем приемлемый вариант.

В питоне всё же есть ООП и метапрограммирование, многие вещи пишутся гораздо проще и быстрее. Но в долгосрочной перспективе я бы предпочёл Go.

В чем профит тогда юзать вообще это все, если можно взять Go

Профит в том, что на питоне писать приятнее. Лично я когда берусь что то делать на любом другом языке, постоянно ловлю себя на мысли «Как же просто и элегантно я бы вот это сделал на питоне».

а у вас там что, до сих пор таблицами лочат? вы из какого века пишете, мсье?

в таком случае архитектору базы по голове надо постучать.

но я всеравно скажу, что пул коннектов в вебе держать нет смысла, если это не вебсокеты конечно.

Как же просто и элегантно я бы вот это сделал на питоне

Лорчую.

Но такие же мысли бывают и при написании кода на питоне. «Здесь я бог бы не копировать память, а здесь мог бы распараллелить».