Он будет держать в кеше страницы, которые пользователи посещали, и сбрасывать кеш по необходимости, когда он протухает, это не требует никаких вычислительных мощностей для сервера и никак не замедляет работу деплоев и тд
Это были абстрактные цифры, потому и написал, что в вакууме.
Не важно сколько весят все шаблоны, важно то, что при генерации страниц, зря занимается дискове место на сотни, а то и тысячи файлов, что тоже рождает свои проблемы, по деплою, перегенерации
Вот представьте, у вас магазин, в нем 10 000 товаров. Какой-то менеджер делает импорт товаров, новых, 2 000 и изменяет еще 1 000 старых, нужно просто так, сделать генерацию 3-х тысяч шаблонов + шаблоны связанных страниц. Скрыть товар из продажи, что, дропать HTML шаблон?
Лишние и бесполезные действия. Спор не уместен, не сможете убедить, что каждый раз дублировать данные это гениальное решение.
Изменись у вас 1 атрибут, цена, артикул, да что угодно, вам нужно перерендерить 100500 шаблонов с этими данным. Это затратно по времени и в целом N+1 операция.
В то время, когда кешируются данные (подготовленные к рендерингу, в нужном формате и тд) рендеринг занимает миллисекунды и выполняется только при необходимости, по факту
Дублирование всей верстки, каждый раз делая ПРЕгенерацию всех страниц вы дублируете 1 шаблон на количество страниц с этими данными, пускай у вас магазин, в нем 10 000 товаров, у вас есть 1 шаблон, вы вместо того, чтобы в 1 шаблон врендеривать маленький хешик\json создаете 10 000 HTML страниц
Ну, так и рассматривайте пре-рендеринг как прогретый файловый кеш с ручной инвалидацией, что не так?
Это неоптимально и в корни неверно. Кешировать надо данные, а не полный HTML страницы. Если прям очень хочется, можно включить кеширование на Nginx
Это называется палить из пушки по воробьям, для таких вещей существует кеширование, как данных, так и определенных темплейтов, шапка сайта? ок, ее закешить не вопрос, это данные которые меняются раз в тысячелетие, а каждый раз генерить полную HTML версию под каждый товар, это тоже самое, что для каждой рисинки делать отдельную упаковку
Механизм рендеринга 1 — данных много.
А так получается мы делаем дубликацию шаблонов с заполненными данным, вместо того, чтобы сайт весил 500 мб в вакууме, он будет весить N на M+k, где N размер 1 шаблона и M количество шаблонов и k размер данных
я хотел бы посмотреть, как вы ту же например википедию будете хранить таким образом и сколько места у вас займет
Это как раз таки не правильно, потому что если хранить уже конечный результат выходит огромное дублирование и оверхед.
Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.
Необязательно хранить структуру данных, что в БД в кеше, можно хранить в кеше подготовленные, данные, т.е презентованные, под нужную структуру, выборка из связанных таблиц и тд.
Данные в любом случае будет занимать меньше места, чем хранение HTML. Тем более, можно делать хранение, только основных данных, выборка которых занимает основную часть времени.
Вариантов работы с кешом масса, можно всегда прогревать кеш заранее, а можно делать это только при первом обращении, или только определенных записей, решение индивидуально под проект и проблемы которые возникают с производительностью
Опять же, кеш не панацея, если что-то тупит, надо чинить там, а генерировать готовый шаблон на этапе сборки, как описано в статье это самое последнее, что можно придумать
Зачем генерировать статические страницы?
У вас есть данные, вы переживаете, что они медленно выгружаются, потому хотите генерить статику, но это не логично, вы по сути кешируете HTML, в то время, как можно закешировать данные о заказе, а то как он будет отображен, уже дело 10-е и не такое уж и долгое, особенно при серверном рендеринге, у вас же не хайлоады как у яндекса на поиске.
Итого, товар в кеше, сбрасываемый\обновляемый, если данные товара изменились, а рендеринг работает уже по выгруженным данным из кеша, все, в БД ходим крайне редко, скорость работы отличная, для 95% сайтов будет работать оптимально
Запросов то может и меньше, а вот объем данных больше, тут же подразумевается уже работа с отренндренными шаблонами, значит мы передаем их, в то время, когда в классическом SPA мы можем использовать либо клиенский либо серверный рендеринг.
Причем в случае клиентского, с бекенда придут только данные, и скорее всего, их трафику явно будет меньше, чем HTML разметка.
Ну и опять же, подход описанный в статье, это чисто для статических сайтов.
Та да, а потом в команде полно самозванцев, которые в скилах зеро, зато у них хороший софт-скил! А потом получаем кучу некачественного кода, который тупит и не хочет работать, а когда говоришь, что ваш код «пахнет» ты токсичный
Так я не понимаю одновременно вашей проблемы, вот у вас была улица А, она переименовалась в улицу Б, значит это история записи А -> Б, вы отдельно храните атрибут имени, как свойство, связывая, вы указываете нужный атрибут, все
Когда улица меняется, она создается НОВАЯ, а не изменяется старая, но связка есть с старой, для «истории» и соотношения
Значит, такая логика справедливо именно в вашем случае, потому, что это ваша бизнес логика, чтобы данные крепились к состоянию за то самое время и не менялись.
Но это нельзя назвать универсальной логикой, она не всем нужна и в 90% проектов будет избыточной.
Утверждение верное, но не полное, как по мне, определенные технологии могут и решают определенные задачи лучше, быстрее, качественнее.
Так что к теме этой статьи — разработка в вебе на рельсе это быстро и хорошо, другие стеки могу быть как натягивание совы на глобус, в то время, когда в другой сфере, они на голову выше руби
Интерфейсов, временами, не хватает, но это другой разговор)
В сторону интерфейсов, могу посоветовать посмотреть на Sorbet, фактрически, аналогичное можно написать и своими силами, но мы у себя в проекте решили попробовать, в итоге выглядит хорошо и удобно
Если говорить именно про определение уязвимостей, то мы в своих проектах используем Bundler Audit (https://github.com/rubysec/bundler-audit) 1 командой проверяет наличие потенциальных уязвимостей в гемах
на счет стайлинга, я ж правильно понимаю, что это код стайл? для этого есть RuboCop, на котором можно так же делать свои собственные настройки под проект, кроме тех, что предоставляется из коробки
Не важно сколько весят все шаблоны, важно то, что при генерации страниц, зря занимается дискове место на сотни, а то и тысячи файлов, что тоже рождает свои проблемы, по деплою, перегенерации
Вот представьте, у вас магазин, в нем 10 000 товаров. Какой-то менеджер делает импорт товаров, новых, 2 000 и изменяет еще 1 000 старых, нужно просто так, сделать генерацию 3-х тысяч шаблонов + шаблоны связанных страниц. Скрыть товар из продажи, что, дропать HTML шаблон?
Лишние и бесполезные действия. Спор не уместен, не сможете убедить, что каждый раз дублировать данные это гениальное решение.
В то время, когда кешируются данные (подготовленные к рендерингу, в нужном формате и тд) рендеринг занимает миллисекунды и выполняется только при необходимости, по факту
Это неоптимально и в корни неверно. Кешировать надо данные, а не полный HTML страницы. Если прям очень хочется, можно включить кеширование на Nginx
Механизм рендеринга 1 — данных много.
А так получается мы делаем дубликацию шаблонов с заполненными данным, вместо того, чтобы сайт весил 500 мб в вакууме, он будет весить N на M+k, где N размер 1 шаблона и M количество шаблонов и k размер данных
я хотел бы посмотреть, как вы ту же например википедию будете хранить таким образом и сколько места у вас займет
Не нужно складывать все в одну корзину, рендиринг это одна функция, данные другая, рендерить данные быстро, а получать данные нет, потому кеширование и оптимизацию решают проблему получения.
Данные в любом случае будет занимать меньше места, чем хранение HTML. Тем более, можно делать хранение, только основных данных, выборка которых занимает основную часть времени.
Вариантов работы с кешом масса, можно всегда прогревать кеш заранее, а можно делать это только при первом обращении, или только определенных записей, решение индивидуально под проект и проблемы которые возникают с производительностью
Опять же, кеш не панацея, если что-то тупит, надо чинить там, а генерировать готовый шаблон на этапе сборки, как описано в статье это самое последнее, что можно придумать
У вас есть данные, вы переживаете, что они медленно выгружаются, потому хотите генерить статику, но это не логично, вы по сути кешируете HTML, в то время, как можно закешировать данные о заказе, а то как он будет отображен, уже дело 10-е и не такое уж и долгое, особенно при серверном рендеринге, у вас же не хайлоады как у яндекса на поиске.
Итого, товар в кеше, сбрасываемый\обновляемый, если данные товара изменились, а рендеринг работает уже по выгруженным данным из кеша, все, в БД ходим крайне редко, скорость работы отличная, для 95% сайтов будет работать оптимально
Причем в случае клиентского, с бекенда придут только данные, и скорее всего, их трафику явно будет меньше, чем HTML разметка.
Ну и опять же, подход описанный в статье, это чисто для статических сайтов.
Тем более, перекладывать нагрузку на браузер, не самое оптимальное решение, в случае слабого интернета или компьютера пользователей.
Когда улица меняется, она создается НОВАЯ, а не изменяется старая, но связка есть с старой, для «истории» и соотношения
Но это нельзя назвать универсальной логикой, она не всем нужна и в 90% проектов будет избыточной.
Можно решать и другим способом, путем копирования данных, аля история, и завяки это просто отдельные сущности, никак не связанные с основной.
Так что к теме этой статьи — разработка в вебе на рельсе это быстро и хорошо, другие стеки могу быть как натягивание совы на глобус, в то время, когда в другой сфере, они на голову выше руби
В сторону интерфейсов, могу посоветовать посмотреть на Sorbet, фактрически, аналогичное можно написать и своими силами, но мы у себя в проекте решили попробовать, в итоге выглядит хорошо и удобно
Все упирается в человеческий и организационный фактор на проекте
на счет стайлинга, я ж правильно понимаю, что это код стайл? для этого есть RuboCop, на котором можно так же делать свои собственные настройки под проект, кроме тех, что предоставляется из коробки