О каких проблемах Tailwind вы говорите? В случае большого проекта можно использовать и комбинированный подход.
С CSS-in-JS пожалуй соглашусь, все таки использовался он не часто, упомянул о нем скорее вскольз. (может попросить если хочешь)
CSS модули хороши, но в случае если вам необходимо разметить сетку или отступы какое-либо, тут на мой взгляд лучше использовать утилити классы либо самописные, либо того же Tailwind.
Если зависимых объектов несколько, то да, они тоже уходят в «ожидание», пока не появится ключевая сущность. Это позволяет держать целостность и не плодить пустые записи.
Подход с болванками мы тоже рассматривали. Он выглядит логично, но в больших обменах приводит к куче «пустышек», которые потом трудно отличать от реальных данных. В результате выше риск ошибок и лишних связей.
Мы нашли баланс: для критичных сущностей (например, клиент) иногда создаем минимальную «болванку», чтобы можно было на неё сослаться. Но в общем случае проще и надежнее держать в статусе ожидания и достраивать, когда данные реально пришли
Справедливо. ELK действительно прожорливый и требует ресурсов. Но у ELK остаются свои сильные стороны: быстрый полнотекстовый поиск, зрелая экосистема и огромное количество готовых интеграций. Если инфраструктура большая и ресурсы позволяют, стек все еще актуален. А для более компактных проектов как раз лучше подойдут современные «лёгкие» варианты.
Мы хотели сделать обзор, показать, зачем использовать Zabbix и ELK вместе и как они работают вместе. «Мясо» в кейсе с падением базы в 5 утра: Zabbix прислал алерт, ELK помог найти тяжелые запросы.
Да, это так. В e-commerce почти никогда не получается отобразить данные «как есть». Почти всегда нужна прослойка, которая преобразует их под логику сайта и ожидания пользователей - маппинг, адаптеры, иногда даже своя модель каталога.
Если объект ссылается на то, чего ещё нет, мы его не теряем, а сохраняем «в ожидании». Когда связанный объект приезжает, система достраивает связь. Если он так и не появился, то отмечаем ошибку и можно повторно запросить данные. Так порядок прихода уже не критичен.
Спасибо за вопрос! В легаси-проектах главное — не пытаться внедрить всё сразу. Лучше идти маленькими шагами: выбрать один понятный кейс, обернуть его простыми тестами и добавить «мягкую» валидацию (сначала просто логировать ошибки, не ломая процесс).
Так команда видит, что изменения реально помогают, а не мешают. Со временем проверки можно сделать строже и расширить на другие участки кода. Такой постепенный подход снижает риски и сопротивление внутри команды.
Наверное и да и нет. Текст показался занимательным, поэтому он тут. Let's Encrypt, интересная тема. Попробую собрать слова в предложения по этому поводу.
Согласен, подача могла быть лучше — постараюсь учесть это в будущем. Здесь я ориентировался на перевод, стараясь не отклоняться от оригинала.
Главное, что хотел донести: open source и self-hosted решения могут нести скрытые риски, превращаясь в своего рода "троянского коня", особенно если они зависят от внешних сервисов и не находятся в полностью закрытом контуре. Спасибо за обратную связь!
О каких проблемах Tailwind вы говорите? В случае большого проекта можно использовать и комбинированный подход.
С CSS-in-JS пожалуй соглашусь, все таки использовался он не часто, упомянул о нем скорее вскольз. (может попросить если хочешь)
CSS модули хороши, но в случае если вам необходимо разметить сетку или отступы какое-либо, тут на мой взгляд лучше использовать утилити классы либо самописные, либо того же Tailwind.
Да, видел этот отчёт. Интересно, что при росте популярности Tailwind, SASS/SCSS все еще уверенно держит позиции.
Благодарю за развернутый ответ, есть над чем подумать.
Спасибо за ваше мнение. А чем в вашем случае SASS/SCSS усложняет процесс сборки?
Если зависимых объектов несколько, то да, они тоже уходят в «ожидание», пока не появится ключевая сущность. Это позволяет держать целостность и не плодить пустые записи.
Подход с болванками мы тоже рассматривали. Он выглядит логично, но в больших обменах приводит к куче «пустышек», которые потом трудно отличать от реальных данных. В результате выше риск ошибок и лишних связей.
Мы нашли баланс: для критичных сущностей (например, клиент) иногда создаем минимальную «болванку», чтобы можно было на неё сослаться. Но в общем случае проще и надежнее держать в статусе ожидания и достраивать, когда данные реально пришли
Да, ELK уже не так хайпово выглядит, но живёт и используется. Особенно там, где нужен быстрый поиск по логам и мощная аналитика :)
Справедливо. ELK действительно прожорливый и требует ресурсов. Но у ELK остаются свои сильные стороны: быстрый полнотекстовый поиск, зрелая экосистема и огромное количество готовых интеграций. Если инфраструктура большая и ресурсы позволяют, стек все еще актуален. А для более компактных проектов как раз лучше подойдут современные «лёгкие» варианты.
Спасибо за комментарий :)
Мы хотели сделать обзор, показать, зачем использовать Zabbix и ELK вместе и как они работают вместе. «Мясо» в кейсе с падением базы в 5 утра: Zabbix прислал алерт, ELK помог найти тяжелые запросы.
Да, это так. В e-commerce почти никогда не получается отобразить данные «как есть». Почти всегда нужна прослойка, которая преобразует их под логику сайта и ожидания пользователей - маппинг, адаптеры, иногда даже своя модель каталога.
Если объект ссылается на то, чего ещё нет, мы его не теряем, а сохраняем «в ожидании». Когда связанный объект приезжает, система достраивает связь. Если он так и не появился, то отмечаем ошибку и можно повторно запросить данные. Так порядок прихода уже не критичен.
Спасибо за вопрос! В легаси-проектах главное — не пытаться внедрить всё сразу. Лучше идти маленькими шагами: выбрать один понятный кейс, обернуть его простыми тестами и добавить «мягкую» валидацию (сначала просто логировать ошибки, не ломая процесс).
Так команда видит, что изменения реально помогают, а не мешают. Со временем проверки можно сделать строже и расширить на другие участки кода. Такой постепенный подход снижает риски и сопротивление внутри команды.
Если вы тоже сталкиваетесь с задачами интеграции 1С и e-commerce или думаете, как оптимизировать обмен данными в своем проекте, пишите нам.
Подумал что на автора текста логичнее будет.
Там есть еще интересные тексты, плюс у него в целом не так много материалов.
Как правило open source это self-hosted решение.
Если self-hosted коммерческий / покупной то риски там меньше.
Наверное и да и нет. Текст показался занимательным, поэтому он тут.
Let's Encrypt, интересная тема. Попробую собрать слова в предложения по этому поводу.
LLM была, но все чуть сложнее.
Был google, далее ручками, а далее уже claude.ai
Каюсь
Просмотрел, поправил. Спасибо.
Уже создан котел в аду для таких как я.
Вот тут данная ситуацию чуть подробнее раскрыта:
https://www.securitylab.ru/news/552957.php
Согласен, подача могла быть лучше — постараюсь учесть это в будущем. Здесь я ориентировался на перевод, стараясь не отклоняться от оригинала.
Главное, что хотел донести: open source и self-hosted решения могут нести скрытые риски, превращаясь в своего рода "троянского коня", особенно если они зависят от внешних сервисов и не находятся в полностью закрытом контуре. Спасибо за обратную связь!