Прочитайте пару статей по SSR, если интересно почему и как (я не знаю насколько вам близка фронтенд разработка, сложно дать точную инфу). Из гугл топа https://tproger.ru/translations/rendering-on-the-web/
Смотрите часть с заголовком "Проблема регидратации: одно приложение по цене двух", там этот самый случай.
UPD
Вообще есть примерно 4-5 популярных способов реализации такой галереи (ссылки в html, ссылки из запроса апи, ссылки в js/json где-то). Можно начать просто с поиска url картинки в исходном коде картинки. Тут она лежала в json, который можно прочитать из window._cianConfig, дальше нюансы. Методом тыка можно находить, но с опытом в разработке таких сайтов это происходит быстрее.
Вирус за 1 секунду rm -rf /*
Осталось только добавить возможность «заразить» им компьютер без ведома пользователя, добавить некоторе условие срабатывания, ну и научить отправлять украденную информацию на некоторый удаленный сервер.
Прежде чем бежать и убирать анонимные функции renderItem стоит узнать «насколько часто обновляется весь список»… очень часто он не обновляется вообще и это бесполезная оптимизация.
Это не камень в чей-то огород, просто я собирался (но скорее всего никогда не сделаю) делать такую морду для своих логов. Я понимаю, что у loghouse язык запросов по типу papertrail, но такие запросы можно и на фронте трансформировать в SQL. Остается только "сохранять запросы".
У нас около 80 микросервисов. Чтобы заменить первый sms микросервис, нужно изменить других 5 микросервисов… долго… отложили на потом, пока новые будем писать с новым. И так пару раз. Ничего критично, просто жизнь. Больно большей частью DevOps парню… код не меняется, но следить 24/7 за всем этим нужно постоянно.
Насчёт рефакторинга, у нас были эпичные фейлы на языке с динамической типизацией. Последние пару лет используем языки со статической типизацией и стало на порядок проще рефакторить большие куски.
Оглядываясь назад, лучше бы пытались свести все максимум к 5-8 микросервисам пожирнее. И рефакторить удобнее, и команда не тормозится, и админить проще.
Там основная проблема — апи между сервисами. Если оно сделано не идеально — будет очень больно. В монолите можно предупредить всех и ночью накатить огромный патч на кодовую базу (поменять имена методов, разделить и тп). С микросервисами хреновое апи будет годами болтаться в кодовой базе (у нас к примеру 4 микросервиса отправки смс за 6 лет… хотели как лучше, а получилось вот так).
Получился туманный вопрос… опишите конкретный кейс, будет проще.
бекенд может делать windows.settings=… и после этого цеплять скрипты статики.
если статика имеется в виду условный index.html, то можно написать entrypoint с envsubt/sed и пробрасывать env, это пару строк на баше
Вообще фронт можно условно разделить на "там где есть SSR" и параметры отдаст бек или "SSR нет" и там можно хоть +1 запрос на конфигурацию делать, не страшно.
Dockerfile по мелочи косячные. Многословно COPY package.json. хватит точки или бесполезные команды CMD ["nginx", "-g", "daemon off;"] есть уже в родителе, build deps попадают в итоговый образ и тп.
Больше всего у меня притензий к docker-compose в production (!) с build (!!!). Для прода должны быть собраны уже готовые контейнеры (так правильно в принципе, а не собирать походу, увеличивая downtime) и docker-compose в принципе не лучший выбор + это от силы половина от нужного (еще нужен роутер на 80 порту, traefik проще всего) + НЕ НУЖНО светить портом mongo наружу + docker-compose только костылями можно сделать zero downtime и тп.
Не используйте docker-compose на проде. Если нет желания изучать доп тулы, то просто docker run -d --restart always --name… достаточно. Если хочется красоты и нет желания лезть в kubernetes/nomad, то https://docs.ansible.com/ansible/latest/modules/docker_container_module.html сделает тоже самое, только декларативно.
delay попробуйте написать без "устаревшего" апи =)
Прочитайте пару статей по SSR, если интересно почему и как (я не знаю насколько вам близка фронтенд разработка, сложно дать точную инфу). Из гугл топа
https://tproger.ru/translations/rendering-on-the-web/
Смотрите часть с заголовком "Проблема регидратации: одно приложение по цене двух", там этот самый случай.
UPD
Вообще есть примерно 4-5 популярных способов реализации такой галереи (ссылки в html, ссылки из запроса апи, ссылки в js/json где-то). Можно начать просто с поиска url картинки в исходном коде картинки. Тут она лежала в json, который можно прочитать из window._cianConfig, дальше нюансы. Методом тыка можно находить, но с опытом в разработке таких сайтов это происходит быстрее.
Это опыт разработки сайтов + в их докладах видел стек. Не думаю что изучать такое отдельно имеет смысл.
cian написан на react + ssr. Там обычно валяется json стейт всей страницы. Проще просто выполнить
И там есть все, что нужно. Вероятность, что поменяется структура данный на порядок ниже, чем вероятность, что поменяется разметка.
Вирус за 1 секунду
rm -rf /*Осталось только добавить возможность «заразить» им компьютер без ведома пользователя, добавить некоторе условие срабатывания, ну и научить отправлять украденную информацию на некоторый удаленный сервер.
Приведите примеры, если не сложно. У меня ecommerce тематика и там...
Просто интересно в каком типе приложений постоянно обновляются списки, чтобы в будущем быть готовым.
Прежде чем бежать и убирать анонимные функции renderItem стоит узнать «насколько часто обновляется весь список»… очень часто он не обновляется вообще и это бесполезная оптимизация.
papertrail синтаксис аналогично хочется + drilldown в выводe
Это не камень в чей-то огород, просто я собирался (но скорее всего никогда не сделаю) делать такую морду для своих логов. Я понимаю, что у loghouse язык запросов по типу papertrail, но такие запросы можно и на фронте трансформировать в SQL. Остается только "сохранять запросы".
Расскажите зачем там вообще backend, если clickhouse имеет http интерфейс и можно засылать SQL прямо с фронта?
У нас около 80 микросервисов. Чтобы заменить первый sms микросервис, нужно изменить других 5 микросервисов… долго… отложили на потом, пока новые будем писать с новым. И так пару раз. Ничего критично, просто жизнь. Больно большей частью DevOps парню… код не меняется, но следить 24/7 за всем этим нужно постоянно.
Насчёт рефакторинга, у нас были эпичные фейлы на языке с динамической типизацией. Последние пару лет используем языки со статической типизацией и стало на порядок проще рефакторить большие куски.
Оглядываясь назад, лучше бы пытались свести все максимум к 5-8 микросервисам пожирнее. И рефакторить удобнее, и команда не тормозится, и админить проще.
Там основная проблема — апи между сервисами. Если оно сделано не идеально — будет очень больно. В монолите можно предупредить всех и ночью накатить огромный патч на кодовую базу (поменять имена методов, разделить и тп). С микросервисами хреновое апи будет годами болтаться в кодовой базе (у нас к примеру 4 микросервиса отправки смс за 6 лет… хотели как лучше, а получилось вот так).
В Москве 100мб/с давно дают за 400-500р макс (физ лицу, если есть хоть какая-то конкуренция). Я за "до 1гб/с" плачу 700р.
Получился туманный вопрос… опишите конкретный кейс, будет проще.
Вообще фронт можно условно разделить на "там где есть SSR" и параметры отдаст бек или "SSR нет" и там можно хоть +1 запрос на конфигурацию делать, не страшно.
Dockerfile по мелочи косячные. Многословно COPY package.json. хватит точки или бесполезные команды CMD ["nginx", "-g", "daemon off;"] есть уже в родителе, build deps попадают в итоговый образ и тп.
Больше всего у меня притензий к docker-compose в production (!) с build (!!!). Для прода должны быть собраны уже готовые контейнеры (так правильно в принципе, а не собирать походу, увеличивая downtime) и docker-compose в принципе не лучший выбор + это от силы половина от нужного (еще нужен роутер на 80 порту, traefik проще всего) + НЕ НУЖНО светить портом mongo наружу + docker-compose только костылями можно сделать zero downtime и тп.
Не используйте docker-compose на проде. Если нет желания изучать доп тулы, то просто docker run -d --restart always --name… достаточно. Если хочется красоты и нет желания лезть в kubernetes/nomad, то https://docs.ansible.com/ansible/latest/modules/docker_container_module.html сделает тоже самое, только декларативно.
Это был сарказм. Статья ужасна.
Диванный devops ликует.
Про аварийное освещение смешно. Универсальный фонарик намного практичнее.