Давай сравним скорость

а так вышло быстрее, чем marshmallow, serpy и drf

Скорость сериализации drf меня вгоняет в тоску

Чёт я не сразу понял, что это твоё

Сорри

))

Как альтернативу marshmallow можно посмотреть https://github.com/lyft/toasted-marshmallow

там по-сути кодогенерация сериалайзера на основе marshmallow-схем происходит

Мне маршмеллоу не нравится тем, что надо ещё какие-то схемы отдельно писать

Мне маршмеллоу не нравится тем, что надо ещё какие-то схемы отдельно писать

Ну есть, например, https://github.com/justanr/marshmallow-annotations

Жсон схема, маршмеллоу схема, потом датакласс и наконец модель алхимии. И везде блин одни и те же поля

генерация схем по dataclass'ам, attrs, namedtuple

Жсон схема, маршмеллоу схема, потом датакласс и наконец модель алхимии. И везде блин одни и те же поля

json-схему уже точно можно генерить по marshmallow-схеме

json-схему уже точно можно генерить по marshmallow-схеме

Нельзя. Это ж документация к апи фактически.

Она должна быть независима от реализации

То есть технически можно, но имхо не стоит, иначе хрен изменения найдешь

Ее же не только твой сервер будет юзать

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

Вот скорее наоборот уж

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

Git flow

Нельзя. Это ж документация к апи фактически.

Ну поэтому как раз и можно. Чтобы документация была в консистентном состоянии с api

Ну поэтому как раз и можно. Чтобы документация была в консистентном состоянии с api

Если бы этим никто не пользовался, она будет. Но эту схему же ещё клиенты юзают

Как она к ним попадет? Путем сборки сервера из сорцов?

Сервер же налету это может генерить

Именно. А клиентский код на лету не сгенеришь

Он блин написан и проверен на соответствие апи, которое выдали

Так а ручное написание json-схем какую проблему решает

Проблему версионирования апи

если у тебя поменялось апи, но не поменялась json-схема для него, то что это решит?

И согласования кода сервера и клиента

там по-сути кодогенерация сериалайзера на основе marshmallow-схем происходит

А у меня кодогенерация на основе схемы датакласса происходит, та же идея

если у тебя поменялось апи, но не поменялась json-схема для него, то что это решит?

Ты увидишь, что сервер не принимает валидные данные и будешь фиксить сервер. Иди поменяешь схему и пойдешь всем рассказывать об этом

А у меня кодогенерация на основе схемы датакласса происходит, та же идея

Вот это имхо правильнее

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

А что, за гит флоу дискусса не будет?

Ты увидишь, что сервер не принимает валидные данные и будешь фиксить сервер. Иди поменяешь схему и пойдешь всем рассказывать об этом

Я смогу увидеть breaking change в API по изменению его схемы даже без того чтобы отправлять реальный запрос

И это должно происходить еще на этапе CI

Я смогу увидеть breaking change в API по изменению его схемы даже без того чтобы отправлять реальный запрос

Разработчики клиентов как твои изменения узнают? Сами догадаются?

Табы на пробелы замени

Почитать про pep8

Разработчики клиентов как твои изменения узнают? Сами догадаются?

Если это не breaking change им ничего знать не обязательно

Нажми ctrl-alt-shift L или как там

а breaking changes быть не должно

Любое изменение схемы может быть breaking. Или у тебя 100% покрытие?

Короче, я за генерацию кода из жсон схемы. А не наоборот

Любое изменение схемы может быть breaking. Или у тебя 100% покрытие?

Нет, не любое. Например, добавление поля в response не должно являться breaking change

Или сваггер

Нет, не любое. Например, добавление поля в response не должно являться breaking change

Может стать. Если клиент ожидает строго определенный набор полей

Реализации разные

Некоторые плохие

Если кто-то не использует tolerant reader, то он ССЗБ

но если делается публичное апи, то с этим конечно сложнее

Это понятно.

Эмм. Везде где больше 2 человек и есть деление на команды апи становится своего рода публичным по отношению к тебе

В компании могут быть конвеншены, что любой потребитель апи должен являться tolerant reader. Если клиент упадет из-за появления необязательного поля в api, то виноват будет именно разработчик клиента

И это работает и в случае с 2+ разработчиками и в случае с 20+

Если не придерживаться таких правил, то получится, что либо ты вообще не сможешь менять свои апи, либо будешь поддерживать 10ки версий одного и того же api

Если интересно могу рассказать как мы реализовывали матчинг совместимости клиентов и серверов на стадии CI

В компании могут быть конвеншены, что любой потребитель апи должен являться tolerant reader. Если клиент упадет из-за появления необязательного поля в api, то виноват будет именно разработчик клиента

Да кто ж спорит. Но если ты отдал клиенту новое описание - он может проверить не дурак ли он. А если умолчал - увы

Если интересно могу рассказать как мы реализовывали матчинг совместимости клиентов и серверов на стадии CI

Расскажи

У нас как правило согласованное обновление было. Либо сохраняли старые методы без изменений для старых клиентов

У нас как правило согласованное обновление было. Либо сохраняли старые методы без изменений для старых клиентов

В больших проектах не всегда возможно найти всех потребителей апи

В больших проектах не всегда возможно найти всех потребителей апи

Тем важнее версионировать апи. Даже минорные версии, которые не ломают совместимость, вроде

Каждый микросервис предоставляет (геренирит налету) свою серверную сваггер-схему. Каждый клиент который использует какой-то метод api, описывает в своей анотации какую схему request/response он ожидает от сервера (это может делаться кодогенерацией, либо руками), эта анотация используется при вызове клиентом апи для сериализации/десериализации запроса/ответа. Таким образом каждый микросервис налету может сгенерировать для каждого используемого им api сваггер-схему того как выглядит этот api с точки зрения этого клиента. Дальше можно сматчить эти две схемы и получить diff, по-которому можно понять есть ли там breaking change. Помимо этого, можно понять есть ли вообще клиенты у api, которые используют какое-то поле, чтобы можно было его выпилить

в чате есть доктор? тут человеку плохо

Каждый микросервис предоставляет (геренирит налету) свою серверную сваггер-схему. Каждый клиент который использует какой-то метод api, описывает в своей анотации какую схему request/response он ожидает от сервера (это может делаться кодогенерацией, либо руками), эта анотация используется при вызове клиентом апи для сериализации/десериализации запроса/ответа. Таким образом каждый микросервис налету может сгенерировать для каждого используемого им api сваггер-схему того как выглядит этот api с точки зрения этого клиента. Дальше можно сматчить эти две схемы и получить diff, по-которому можно понять есть ли там breaking change. Помимо этого, можно понять есть ли вообще клиенты у api, которые используют какое-то поле, чтобы можно было его выпилить

Прикольно в целом

Из-за того что у каждого клиента используется схема, то это гарантирует что клиент использует/отправляет только те поля, которые описаны в схеме

Ну и понятно что внутри компании каждый разработчик не пишет свой велосипед для всего этого. У него просто есть набор библиотек для клиента/сервера, которые все это делают за него автоматически. Ему лишь надо описать(сгенерировать) схемы в приложении

в компании ооо "сказка"

в компании ооо "сказка"

Не знаю что там в сказке, но это вполне себе true-story

Можешь посмотреть, как это, например, делают в циане: https://www.youtube.com/watch?v=ANDGRmKKEG0

в компании ооо "сказка"

Нет, в любой нормальной

Корректный подход

никто не подскажет как получить из базы (mysql) username пользователя? к примеру после команды /start записывается username пользователя и как получить этот юзернейм?

никто не подскажет как получить из базы (mysql) username пользователя? к примеру после команды /start записывается username пользователя и как получить этот юзернейм?

Гугли SQL-запросы

никто не подскажет как получить из базы (mysql) username пользователя? к примеру после команды /start записывается username пользователя и как получить этот юзернейм?

Библиотека sqlite + SQL запросы

причем тут библиотека sqlite, когда я писал про mysql и библиотека там pymysql

pyTelegramBotAPI

Тут юзернейм

ну при команде /start записывается его юзернейм в таблицу и так каждый раз. А я хочу получать с этой таблицы юзернейм этот что бы одного и того 100 раз не записывало

ну при команде /start записывается его юзернейм в таблицу и так каждый раз. А я хочу получать с этой таблицы юзернейм этот что бы одного и того 100 раз не записывало

Тебе уже все ответили

ну при команде /start записывается его юзернейм в таблицу и так каждый раз. А я хочу получать с этой таблицы юзернейм этот что бы одного и того 100 раз не записывало

Селект!

+ я получаю список всех юзернеймов, как только теперь сделать проверку на то, есть ли среди них юзернейм

+ я получаю список всех юзернеймов, как только теперь сделать проверку на то, есть ли среди них юзернейм

Блять, Алёша

Ты не Дима, ты Алёша

Тебе всё уже сказали

Полностью за тебя делать не будут

боже, что ты мне сказал? два раза сказал что мне уже ответили? и один раз что нужно идти гуглить?

ребят кому не сложно и разбираеться в питоне напишите плиз в личку а то я с этим ботом уже мозг сломал