Implement arch invalidation mechanism in the bem server

[bem-archive]

Implement arch invalidation mechanism in the bem server

[veged]

Почему инвалидация не получается просто по построению? Вопрос ведь сводится не к инвалидации всей архитектуры, а к экономии на перевычисление некоторых целей. Например, мы можем считать, что делать апдейт из репозитория чаще чем раз в сколько то времени нет смысла. Т.е. фактически если что-то и выражается в терминах таймаутов, то это не вопрос перестроения архитектуры (его и нет как такового централизованного, всё делается в разных узлах), а вопрос деланья чего-то тяжёлого внутри узлов.

[scf2k]

Мы решили сделать так как временное решение (когда сделаем и попробуем на реальных проектах - будет видно что делать дальше) для случаев, когда запрашивается, например, страница:

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

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

[arikon]

@veged Это не про инвалидацию нод, это про инвалидацию архитектуры сборки.

У нас сейчас нет идей, как сделать её правильной: на каждый запрос (по депендам) — дорого + сложная реализация + возможные конфликты, когда собираем несколько нод одновременно. В качестве иллюстрации смотри схему: https://github.com/bem/bem-bl-test/raw/server/doc/build-graph.png

Решение, которое описал Вова, мы придумали, чтобы быстрее получить работающий прототип bem server.

[arikon]

Поговорили ещё раз. Есть предложение не делать инвалидацию с таймаутом внешним процессом по отношению к процессу сборки.

А делать перестройку на уровне нод, но с таймаутом, чтобы не было оверхеда.
Осталось ещё раз внимательно подумать, будут ли с этим не решаемые проблемы.

[arikon]

See #66