Ищу Candidat CMS

С фильтрами, если не хотите показывать товар out of stock придется да, сгружать в пользователя новую инфу.

При большом ассортименте, вероятно придется не базу целиком, а "патчи" ему присылать. Но это вполне посильно.

Не очень понимаю в чем проблема в генерации десятков тысяч страниц при изменении курса.

(кстати, откуда они взялись в магазине на тысячу товаров :) ?)

Вы их и так сгенерируете, как только любой поисковый бот или юзер придет.... только будете делать это неоднократно.

А перегенерить можно и аккуратно, в удобный момент.

Но да, согласен, если в среднем у вас что-то там обновляется гораздо чаще, чем пользователи видят страницу, то да, скорее всего её имеет смысл формировать что-то "к показу" только по запросу.

Но мне казалось это для дорвеев, а не ИМ актуально.

Тут не только в точке отказа проблемы.

С одной стороны система при которой страницы каждый раз генерятся для показа однозначно порочна.

Да, можно решать эту проблему через кеши, но как правило получается не очень прямо.

Собственно в описанной схеме ваш ИМ - это и есть кеш вашей системы управления :) приготовленный для показа пользователю.

Его и инвалидируем.

С другой стороны система, в которой в slq базу зачем-то записано "всё" для меня тоже как-то "верхом совершенства" не является.

Я вижу к чему это приводит в даже довольно популярных продуктах.

Безусловно есть немало кейсов, в которых надо использовать БД.

Но я не могу себе представить кейс в котором надо использовать БД для хранения названия ИМ :).

А ведь хранят. Многие.

А дальше логичное развитие мысли: что еще не нужно в БД...

С третьей стороны всё становится совсем грустно когда начинаешь думать как-бы ты сам подобную систему "ронял".

Ну т.е. где и какие те самые "точки отказа". Как нагрузить сервера. Итд итп.

И как-то идея писать что-то нужное не только ИМ в его базу сразу перестает быть... актуальной.

А значит... придется где-то всё это хранить, синхронизировать, еще и в две стороны иногда... итд итп.

Название – это хранимая опция. Опции и настройки конфигурации можно хранить как в реляционной БД, так и в отдельных файлах – вопрос вкуса и конкретного их использования.

Посадочные под фильтры, например категория велосипеды может содержать посадочные:

- Велосипеды шоссе

- Недорогие велосипеды шоссе (например до 600$)

- Велосипеды шоссе карбон (материал рамы = карбон)

- Велосипеды МТБ

- Недорогие велосипеды МТБ (опять таки, до 600$)

- Велосипеды МТБ карбон (материал рамы карбон)

При этом участвуют все фильтры

- Фляги {красная,зеленая,черная} для велосипеда

- Покрышки 2.10 27.5" для кросс-кантри tubeless (фильтры: ширина = 2.10, диаметр=27.5, тип=безкамерная, стиль_езды=кросс-кантри)

и т.д.

Все эти страницы генерируются под НЧ и СЧ запрос, по сути это не отдельные категории, а комбинация фильтров, например для шоссе велосипедов из карбона имеющая ЧПУ что-то вроде: /category/velosipedy-shosse-material-carbon/, открывая эту страницу попадаешь на страницу категории велосипедов, но с включенными переключалками у фильтров.

Даже на небольшом магазине (1000 товаров), делая посадочные под СЧ и НЧ, можно сделать легко sitemap на 50к страниц, если там много фильтров и возможностей для выбора.

Плюс учтите, товары часто импортируются/синхронизируются с поставщиками, не имея их у себя на складе. Допустим, у поставщика за день могут добавляться 3 позиции, уходить 4. Итого имеем 7 инвалидаций страниц товаров + все страницы где это фигурирует. Поставщиков может быть несколько.

Ваша система вносит излишнюю сложность, которая может окупаться только в случае огромных нагрузок на железо, тогда целесообразней продумать логику препроцессинга страниц. Либо же, когда вы сами пишете под себя, и у вас небольшая витрина с товарами, скорее даже для презентации ассортимента, чем для покупки через неё.

Вероятность того, что на небольшой магазин обрушатся куча трафика и запросов сомнительна.

Я предпочитаю придерживаться принципа KISS и решать проблемы по мере их поступления, как говорил Дейкстра: Простота является залогом надежности.

Вашу идею концептуально можно решать через SPA и кеш ответов от бекенда (и его инвалидацию), это даже лучше, не придеться гонять хидер/футер туда-сюда.

Да в целом так сейчас и решают, применяя по сути SSR и микросервисную архитектуру, но оно все сложно для сопровождения и маленьким компаниям не по карману. Как и в принципе держать ИМ на статике, дешевле и проще пару строк в конфиг nginx прописать

Да нет проблем перегенерить хоть 10, хоть 50, хоть 100к страниц.

В чем сложность-то ?

Все равно вы это УЖЕ делаете при каждом визите в ваш ИМ. Один раз явно проще будет.

Вопрос тут в том, сколько посещений этой страницы за день.

Если 0.01, то да, дороговато выйдет инвалидировать. Если 100, то проблем нет.

Да какая тут сложность-то ?

Данные движутся однонаправлено, все обновления всего сосредоточены в одном месте.

Но соглашусь, вопрос в том как часто что-то "заканчивается", что при этом "делается" и как часто приходят посетители.

Если ассортимент меняется постоянно и при этом посетителей мало, то с точки зрения производительности готовить для них страницы будет дороже.

Можно, конечно, готовить "по запросу", но это как по мне "идеологически неверно".

Это "как повезет".

В моей практике есть случай, когда небольшой форум каждый день атаковал "взбесившийся телевизор".

Ну т.е. реально какое-то мультимедиа устройство засыпало запросами некисло нагружая хостинг.

Если даже небольшой ИМ долбить таким устройством "в поиск" мало может не показаться.

Для меня нет ничего более сложного и ненадежного, чем генерация страницы для каждого юзера "на ходу".

Для меня нет ничего более сложного и ненадежного, чем хранение контактов компании в БД.

Я именно что и предлагаю "решать по мере поступления".

Название магазина записать в ШАБЛОН, количество товара в страницу, итд итп.

А уж если "ну никак", то лепить базы, динамическое обновление итд итп.

Это называется "прогрев кэша".

---------- Добавлено 15.01.2020 в 16:46 ----------

_SP_, вы не понимаете одной вещи, динамический контент на то и динамический. Допустим, есть товар, который фигурирует на 3 тысячах других страниц (категории+фильтры). Сперва хотелось бы услышать от вас, как вы посчитаете точное количество страниц где фигурирует товар. Чтобы сгенерировать эти страницы, вам нужно запросить товары, которые фигурируют на этих страницах (вы же не будете вычленять из DOM HTML ноду и подменять у неё цену, правда?). Также хотелось бы услышать, как вы получите siblings товары, задачка то на самом деле не тривиальная. Изменения позиции первой страницы, затрагивает изменения рендера всех последующих страниц (вы же не хотите чтобы у вас на первой странице было 19 товаров, правда?). Таким образом, меняя один товар, мы генерируем 3к страниц (категории+фильтры), так же нам нужно сделать до 60к запросов к другим товарам (20 товаров на страницу * 3к страниц = 60к запросов), и не важно как близко к ЦПУ вы их храните. Вы действительно считаете, что это проще с точки зрения написания логики, дешевле по ресурсам, чем изменить цену одного грёбаного товара в базе, и рендерить по запросу?!

Кейс простой, когда название магазина нужно использовать как переменную в:

- Шапке и подвале сайта

- В шапке и подвале писем для рассылки

- В SEO заголовках, например: Купить смартфон | Эльдорадо.

- Где-нибудь ещё?

Если вы храните это в файлах, вы можете конечно читать из файла, но где вот эта ваша слейв реплика откуда можно читать до усрачки?

Я скорее понимаю, что в 99% случаев люди зачем-то из статического контента динамический делают.

Ну не цену, а out of stock ?.

Идея с динамическим скрытием, кстати интересная.

Зависит от статистики, т.е. если у вас мало закончившихся товаров, можно и так их "скрывать".

Верно я понимаю, что вас беспокоит, что в момент продажи будут сложности с обновлением фильтров ?

(с категориями обычно проще). Надо подумать. Обходить всё и выгружать только изменившееся не хотелось бы.

Почему нет :) ?

Не, ну правда. Вам реально важно 20 у вас товаров на странице или 19 ?

Вообще... сейчас.... многие... не скрывают товары.... это.... как-бы это сказать. Плохо это :(. Но факт.

Поэтому готового решения прям щаз не рожу, надо подумать на свежую голову.

Если у вас есть посетители может оказаться дешевле. Если нету - дороже.

Вы про шаблоны что-нибудь слышали :) ?

Я прям даже пугаюсь. Хотите в заголовке чтобы в конце было | Эльдорадо. так добавьте в шаблон заголовка "| Эльдорадо. "

Или вы настаиваете на том, что это все должно обязательно взято из одного места ?

Так окажется, что в шапке нужно "Эльдорадо", в подвале "Эльдорадо - лучший шоп", в SEO какой-нибудь "| Купить в эльдорадо", а где-то еще "Эльдорадочка - лучшее место для покупки".

Нет никакого смысла хранить это где-то кроме шаблона, ей богу.

Это стёб такой, или всерьёз? :)

Разве что для поднятия активности на форуме. ;)

Ну вы блин даёте...

Стартпост ещё помните?