Да, всё верно. Наше решение очень быстро, дёшево и сердито, но, как вы верно подметили, и как я упомянул в конце статьи, в случае микросервисов встает вопрос о более "классических" решениях.
Почему? Документация есть, бас фактор в пределах нормы. Если поменялась вся команда разработчиков, аналитиков, РП в момент и не осталось ни одной наскальной надписи о применяющемся решении, то это уже сюр. У меня, к счастью, такого опыта не было)
А так это никому не мешает, сами джсоны на проде мы на корректность не дебажим, да и команда на этом проекте небольшая и все знали об эксперименте)
В статье есть блок в конце, обратите на него внимание, пожалуйста. Это решение даже не рассматривается в проектах с балансерами и т.
Отключается с помощью настроек конфигурации Kotlin Serialization. Плюс, в статье демо пример, на самом деле всё чуточку сложнее. Привести весь листинг кода не было целью.
P. S. Спасибо за статью про сжатие, обязательно почитаем. Только у нас в этом проекте не Spring, а Ktor, но ничего, поменяем стек.
Мы логи на сервере пишем после десериализации запросов и до сериализации ответов, и соответственно в них всё чистенько и читаемо, т. к. пишем по неймингу пропертей, а не полей в джсоне. Зачем дебажить сам джсон на корректность сериализации/десериализации — не знаю. С таким же успехом можно подебажить протокол HTTP. А если идея с помощью, например, чарлика подменять запросы, то для таких вещей есть дев и стейдж окружения, где минификации нет)
И нет, статья не про аннотацию, а про экспериментальный, не самый очевидный вариант её использования, который может быть не жизнеспособен в других обстоятельствах. Если вы где-то ещё видели такой вариант использования — буду рад ознакомиться и понять, что не только мы такие альтернативно одарённые. В целом статья больше для настроения, а для понимания аннотации можно почитать документацию.
Козел светлый, изначально было двое, после половины ящика остался один.
Да, всё верно. Наше решение очень быстро, дёшево и сердито, но, как вы верно подметили, и как я упомянул в конце статьи, в случае микросервисов встает вопрос о более "классических" решениях.
Спасибо за комментарий!
Здесь про конкретный кейс минификации букав. Но, безусловно, вы правы, null тоже не имеет смысла передавать явно.
А разве одно другому мешает?
Спасибо, но уже не актуально( Наш 400к сеньор уже нашел индусский туториал 😎
Можно, но статья не об этом)
О да)
Почему? Документация есть, бас фактор в пределах нормы. Если поменялась вся команда разработчиков, аналитиков, РП в момент и не осталось ни одной наскальной надписи о применяющемся решении, то это уже сюр. У меня, к счастью, такого опыта не было)
А так это никому не мешает, сами джсоны на проде мы на корректность не дебажим, да и команда на этом проекте небольшая и все знали об эксперименте)
В статье есть блок в конце, обратите на него внимание, пожалуйста. Это решение даже не рассматривается в проектах с балансерами и т.
Отключается с помощью настроек конфигурации Kotlin Serialization. Плюс, в статье демо пример, на самом деле всё чуточку сложнее. Привести весь листинг кода не было целью.
P. S. Спасибо за статью про сжатие, обязательно почитаем. Только у нас в этом проекте не Spring, а Ktor, но ничего, поменяем стек.
Да, в таких кейсах, конечно, есть смысл использовать, как в статье написано, зависит от кейса и команды. Мне кажется, там нужно что-то постабильнее
gzip тоже использовали) это своего рода эксперимент
Спасибо за комментарий)
Мы логи на сервере пишем после десериализации запросов и до сериализации ответов, и соответственно в них всё чистенько и читаемо, т. к. пишем по неймингу пропертей, а не полей в джсоне. Зачем дебажить сам джсон на корректность сериализации/десериализации — не знаю. С таким же успехом можно подебажить протокол HTTP. А если идея с помощью, например, чарлика подменять запросы, то для таких вещей есть дев и стейдж окружения, где минификации нет)
И нет, статья не про аннотацию, а про экспериментальный, не самый очевидный вариант её использования, который может быть не жизнеспособен в других обстоятельствах. Если вы где-то ещё видели такой вариант использования — буду рад ознакомиться и понять, что не только мы такие альтернативно одарённые. В целом статья больше для настроения, а для понимания аннотации можно почитать документацию.