LINUX.ORG.RU

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

 , , , ,


3

2

Добрый день.

Поймал себя на том, что при написании какого-либо веб-приложения принято:
1. Описать модель данных, в котором:
поле:тип
поле:тип
...
поле:тип
2. Эту модель замаршаллить специальным маршаллизатором по схеме, в которой
поле:тип
поле:тип
...
поле:тип
3. Эту модель для того, чтобы UI сделать, описать в любимом фреймворке, и там
поле:тип
поле:тип
...
поле:тип
4. Валидатор если писать, в нём тоже... Ну вы поняли.
Периодически натыкался на попытки интеграции всего этого, но слишком сложные. Что, так все и копипастят???

UPD. Всем спасибо, похоже, пора с фласка перелезать на DRF.

★★★★★

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

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

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

Octagon ()
Последнее исправление: Octagon (всего исправлений: 1)

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

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

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

the1 ()
Последнее исправление: the1 (всего исправлений: 1)

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

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

micronekodesu ★★ ()
Ответ на: комментарий от menangen

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

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

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

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

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

dimuska139 ()
Последнее исправление: dimuska139 (всего исправлений: 2)
Ответ на: комментарий от dimuska139

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

Octagon ()
Ответ на: комментарий от dimuska139

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

leave ★★★★★ ()
Ответ на: комментарий от Octagon

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

dimuska139 ()

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

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

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от dimuska139

Пробовал. Всё честно. Но, чем больше кода на питоне, тем тормознутее, конечно, будет итоговый 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 ядра, и одна под бд в той же сети.

menangen ★★★★★ ()
Ответ на: комментарий от Octagon

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

Goury ★★★★★ ()
Ответ на: комментарий от menangen

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

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

Goury ★★★★★ ()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от menangen

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

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

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

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

dimuska139 ()
Ответ на: комментарий от menangen

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

Shadow ★★★★★ ()
Ответ на: комментарий от Octagon

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

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

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

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

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Shadow

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

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

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

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

the1 ()
Последнее исправление: the1 (всего исправлений: 2)
Ответ на: комментарий от the1

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

Shadow ты про это?

Frost ★★★ ()
Последнее исправление: Frost (всего исправлений: 4)
Ответ на: комментарий от Shadow

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

menangen ★★★★★ ()
Ответ на: комментарий от the1

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

Frost ★★★ ()
Ответ на: комментарий от Frost

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

Shadow ★★★★★ ()
Ответ на: комментарий от dimuska139

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

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

dimuska139 ()
Последнее исправление: dimuska139 (всего исправлений: 2)
Ответ на: комментарий от dimuska139

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

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

WitcherGeralt ★★ ()
Ответ на: комментарий от dimuska139

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

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

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от eternal_sorrow

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

Лорчую.

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

WitcherGeralt ★★ ()