В комменте сильно смешалось кучу понятий, буду идти по блокам:
тема user объекта, и его дальнейших обвязок entity, решается обычными handlers.
Хэндлеры могут быть местом, где происходит маппинг между слоями, но сами по себе они не убирают проблему универсального объекта. Если handler принимает, сохраняет и возвращает один и тот же User, тогда смешение ролей просто переезжает внутрь этого самого handler. Ничего общего с решением проблемы, о которой говорится в статье, тут нет.
Также классы в программировании, и особенно в программировании бд, очень странное решение.
Ну тут ок конечно. Я принимаю мнение как альтернативное, но это уровень религиозных войн. Полмира так работает, многие языки построенны именно вокруг ООП, а не являются функциональными или процедурными.
Если вам и надо передавать информацию быстро, то для этого есть gRPC, RocketMQ и NATS.
Этот тезис не относится к проблеме в статье. gRPC, RocketMQ и NATS тоже решают другую задачу: транспорт, RPC или обмен сообщениями. Они не отвечают на вопрос, чем именно является User внутри приложения. Даже поверх всех перечисленных решений можно столько разных объектов и имен накидать, что потом разобраться будет также сложно, как в примерах из статьи.
Также вообще не понятен слой ORM, если у вас и так уже pydantic для валидации используется.
Pydantic отвечает за валидацию и сериализацию данных. ORM — за маппинг состояния в реляционную БД, связи и работу с изменениями. Можно писать без ORM, через SQL или query builder, но это отдельный архитектурный выбор и он никак не противоречит наличию Pydantic в проекте. В общем это два абсолютно разных инструмента сделанных под разные цели.
Очень много boilerplate слоев в логике. Это же жрет драгоценную ПЗУ на SSD.
Очень странный тезис. Это вообще не главный критерий. Главный вопрос — где проходят границы изменения и насколько явно код показывает эти границы, чтобы программисту было удобно. Если бы мы гнались за тем, сколько весит исходный код, то вряд ли писали бы на питоне. Да и это странный тезис для оценки архитектуры в любом языке и проекте.
еще возьмем сюда факт о плохой параллелизации языка python.
К теме статьи это почти никак не относится. Большинство запросов упирается в I/O: БД, сеть, файловое хранилище. GIL не главный аргумент против DTO и тем более против грамотной архитектуры.
Смысл хэширования токена не в том, что SHA-256 улучшает 2048-битный токен. Смысл в другом: значение в базе не должно быть готовым credential.
Да, клиент предъявляет токен в открытом виде, но это не значит, что бэк должен хранить его в сыром виде. При проверке можно принять токен, посчитать hash/HMAC и сравнить с тем, что лежит в базе.
Если утечёт сырой токен — его можно сразу использовать. Если утечёт hash — его нельзя предъявить как токен.
Да, согласен, это хороший плюс UUID/ULID/ObjectId: id можно сгенерировать на стороне приложения до записи в базу, собрать связанные сущности и сохранить весь граф одной транзакцией.
Но “с int практически обязаны сначала сохранить” — это не так. В SQL-базах есть sequence/nextval, INSERT ... RETURNING, ORM flush без commit, заранее выделенные диапазоны id. То есть проблема решаемая, причем несколькими способами.
Я бы сформулировал отличие чуть иначе: при автоинкременте база обычно владеет генерацией id, а приложение синхронизируется с ней. При UUID/ULID/ObjectId генерацией может и чаще всего владеет приложение, и это действительно удобнее для, например, сборки связанных объектов до сохранения.
В статье как раз есть блок про разделение внутреннего _id и публичного public_id:
Если нужен упорядоченный ID внутри — оставляем его внутренним ключом: ObjectId, UUIDv7 или другой вариант, отсортированный по временной метке, чтобы индексу было удобно.
А наружу отдаём отдельный public_id: случайный UUIDv4 или что-то, что не раскрывает время создания.
То есть если в varchar(1000) лежат строки по 20 байт, планировщик после ANALYZE будет видеть примерно эти 20 байт, а не паниковать из-за огромного N, это было бы довольно тупо со стороны СУБД.
Согласен. Для рутины фронтир модели практически всегда избыточны.
Но в реальном процессе цена токенов — далеко не все затраты. Контроль качества, интеграция, ревью.
Короче тут надо искать золотую середину: какая модель не является избыточной для текущей задачи и при этом позволит уменьшить количество итераций до попадания фичи в прод.
Написано мол это будет mythos-class models, то есть не сама мифос, а какая-то облегченная версия что-ли
Короче я буду ждать и верить, что это реально революшн, потому что очень интересно следить как большие компании между собой цапаются буквально каждые пару дней
А какой маркетинговый смысл в том, чтобы дропать свою флагманскую модель и тут же заявлять о том, что через неделю она станет говном? (Ну не флагманской точно)
Столько раскрутки, столько новостей о том, что это самое настоящее кибер-оружие, которое положит чуть ли не половину интернета, чтобы потом вот так выпустить?
Ну даже если это рил, то я не буду верить до последнего, какой-то треш честно говоря полный
В комменте сильно смешалось кучу понятий, буду идти по блокам:
Хэндлеры могут быть местом, где происходит маппинг между слоями, но сами по себе они не убирают проблему универсального объекта.
Если handler принимает, сохраняет и возвращает один и тот же
User, тогда смешение ролей просто переезжает внутрь этого самого handler. Ничего общего с решением проблемы, о которой говорится в статье, тут нет.Ну тут ок конечно. Я принимаю мнение как альтернативное, но это уровень религиозных войн. Полмира так работает, многие языки построенны именно вокруг ООП, а не являются функциональными или процедурными.
Этот тезис не относится к проблеме в статье. gRPC, RocketMQ и NATS тоже решают другую задачу: транспорт, RPC или обмен сообщениями.
Они не отвечают на вопрос, чем именно является
Userвнутри приложения. Даже поверх всех перечисленных решений можно столько разных объектов и имен накидать, что потом разобраться будет также сложно, как в примерах из статьи.Pydantic отвечает за валидацию и сериализацию данных.
ORM — за маппинг состояния в реляционную БД, связи и работу с изменениями.
Можно писать без ORM, через SQL или query builder, но это отдельный архитектурный выбор и он никак не противоречит наличию Pydantic в проекте.
В общем это два абсолютно разных инструмента сделанных под разные цели.
Очень странный тезис. Это вообще не главный критерий. Главный вопрос — где проходят границы изменения и насколько явно код показывает эти границы, чтобы программисту было удобно.
Если бы мы гнались за тем, сколько весит исходный код, то вряд ли писали бы на питоне. Да и это странный тезис для оценки архитектуры в любом языке и проекте.
К теме статьи это почти никак не относится. Большинство запросов упирается в I/O: БД, сеть, файловое хранилище. GIL не главный аргумент против DTO и тем более против грамотной архитектуры.
Наконец новая модель от OpenAI, уже устал смотреть за тем, как клод постоянно выпускает новое, а Сэм Альтман просто катается на своем кенинсинг
Смысл хэширования токена не в том, что SHA-256 улучшает 2048-битный токен.
Смысл в другом: значение в базе не должно быть готовым credential.
Да, клиент предъявляет токен в открытом виде, но это не значит, что бэк должен хранить его в сыром виде. При проверке можно принять токен, посчитать hash/HMAC и сравнить с тем, что лежит в базе.
Если утечёт сырой токен — его можно сразу использовать. Если утечёт hash — его нельзя предъявить как токен.
Да, согласен, это хороший плюс
UUID/ULID/ObjectId:idможно сгенерировать на стороне приложения до записи в базу, собрать связанные сущности и сохранить весь граф одной транзакцией.Но “с int практически обязаны сначала сохранить” — это не так. В SQL-базах есть
sequence/nextval,INSERT ... RETURNING,ORM flushбезcommit, заранее выделенные диапазоныid. То есть проблема решаемая, причем несколькими способами.Я бы сформулировал отличие чуть иначе: при автоинкременте база обычно владеет генерацией
id, а приложение синхронизируется с ней. ПриUUID/ULID/ObjectIdгенерацией может и чаще всего владеет приложение, и это действительно удобнее для, например, сборки связанных объектов до сохранения.В статье как раз есть блок про разделение внутреннего
_idи публичногоpublic_id:Если нужен упорядоченный ID внутри — оставляем его внутренним ключом:
ObjectId,UUIDv7или другой вариант, отсортированный по временной метке, чтобы индексу было удобно.А наружу отдаём отдельный
public_id: случайный UUIDv4 или что-то, что не раскрывает время создания.Да, отличный нюанс, спасибо.
Еще один хороший пример того, почему казалось бы схожую функциональность не стоит воспринимать одинаково в разных СУБД.
Да, я ведь тут и не претендую на открытие. Скорее просто захотелось разобрать миф, о котором я все ещё иногда слышу — так статья и появилась.
Да, только вот это уже другой тезис. Статья не говорит, что ограничения бесполезны. Прежде всего речь о хранении данных
Если же говорить про оптимизатор, то он берет реальные оценки ширины из статистики по фактическим данным, а не из N.
В pg_stats для этого есть avg_width.
То есть если в
varchar(1000)лежат строки по 20 байт, планировщик после ANALYZE будет видеть примерно эти 20 байт, а не паниковать из-за огромного N, это было бы довольно тупо со стороны СУБД.В идеальном мире — да. В таком случае разговор про лишние итерации и оверюз токенов вообще не идёт.
Но на практике сначала идет прикручивание ИИ, а уже потом выясняется, что нет ни нормальных метрик, ни проверки результата)
Согласен. Для рутины фронтир модели практически всегда избыточны.
Но в реальном процессе цена токенов — далеко не все затраты. Контроль качества, интеграция, ревью.
Короче тут надо искать золотую середину: какая модель не является избыточной для текущей задачи и при этом позволит уменьшить количество итераций до попадания фичи в прод.
Да. Это как раз одна из главных мыслей.
ИИ не делает процесс бесплатным и не отменяет ответственность. Он просто меняет структуру затрат.
Локальные агенты больше нинужны?
Кстати да, здравая позиция
Склоняюсь к твоему мнению тоже теперь
Насчёт плагинов рил)
Обсидиан без тем и плагинов - это как машина без двигателя
Я например просто не могу пользоваться обсидианом с дефолтной темой
Может может)))
Ну я скорее не про причину, а в целом про эффект, что такие тулзы обычно лет по 20 уже существуют
А тут прога которая завоевала весь мир за 6 лет, но это неудивительно с ее то подходом
Написано мол это будет mythos-class models, то есть не сама мифос, а какая-то облегченная версия что-ли
Короче я буду ждать и верить, что это реально революшн, потому что очень интересно следить как большие компании между собой цапаются буквально каждые пару дней
А какой маркетинговый смысл в том, чтобы дропать свою флагманскую модель и тут же заявлять о том, что через неделю она станет говном? (Ну не флагманской точно)
Столько раскрутки, столько новостей о том, что это самое настоящее кибер-оружие, которое положит чуть ли не половину интернета, чтобы потом вот так выпустить?
Ну даже если это рил, то я не буду верить до последнего, какой-то треш честно говоря полный
Больше всего я удивился с того, что обсидиан в 2020 создан...
Не в упрек статье, просто я о нем слышу всю жизнь (хотя 6 лет и так вся осознанная моя жизнь лол)