Да, смысл в такой организации веб-движка однозначно есть — идея элегантная, решает классическую боль кэширования (invalidation + stampede) и хорошо ложится на современные тренды. Это по сути content-addressable incremental build system для runtime, а не только для билда. Make/Nix/Bazel уже доказали, что dependency graph + cache-by-hash работает идеально; ты просто переносишь эту модель на веб-страницы.Почему это круто и где уже частично реализованоТочная страница = cache hit, любое отличие = targeted miss
Классические движки собирают страницу «снизу вверх» (запросы в БД → шаблоны → HTML). У тебя наоборот: «сверху вниз» по графу зависимостей. Если весь граф не изменился — отдаём готовый blob из кеша. Это почти точная аналогия Russian Doll Caching в Rails: вложенные фрагменты кэшируются независимо, и изменение внутреннего автоматически инвалидирует только нужное (через updated_at или теги). Или ESI (Edge Side Includes) в Varnish/Akamai — страница собирается из кэшированных кусочков прямо на краю сети.
Сжатие/дедупликация почти одинаковых страниц
Здесь идеально работает content-addressable storage (CAS). Хранишь не полные HTML, а:chunks по их hash (как в Git/IPFS/Nix store),
дерево ссылок (Merkle DAG).
Две страницы с разными аватарками будут делить 99 % блоков. IPFS делает это из коробки + автоматически раздаёт по P2P/DHT (географически ближайший узел отдаёт). Уже есть эксперименты с IPFS как distributed web cache именно для HTML.
CDN/P2P + геобалансировка
Полностью вписывается. В IPFS контент адресуется по CID (hash), а не по URL. CDN (Cloudflare, Fastly) или любой P2P-узел отдаёт ближайшую копию. Плюс можно добавить IPNS или mutable pointers для «живых» версий страницы. Получается гибрид статического сайта и динамического, но с минимальным трафиком на origin.
HTTP-сервер как часть дерева генерации
Это уже почти реализовано в edge computing:Cloudflare Workers + KV + Cache API,
Vercel Edge Functions,
Fastly Compute.
Сервер сам проверяет граф зависимостей и либо отдаёт готовый response (с правильными Cache-Control/ETag), либо запускает только недостающие правила. На miss генерируется не вся страница, а только delta (как make пересобирает только changed targets).
Refal как язык реализации
Здесь ты вообще в точку попал. Refal — это буквально rewriting system, где правила pattern -> replacement — это и есть твои makefile rules. Страница = терм, зависимости = подтермы, генерация = последовательное применение правил. Автоматически получаешь😛attern matching для cache keys,
referential transparency,
суперэффективный граф (Refal-машина оптимизирована именно под такое).
Готовых веб-движков на Refal почти нет (были эксперименты с SGML/XML в 90-х, но не современный веб), так что ты можешь сделать первый настоящий. Refal-5/Refal-6 + современный интерпретатор (есть на Rust/Go) + bindings к HTTP/IPFS — и готово.
Реальные аналогии из индустрии (чтобы не изобретать велосипед заново)Next.js ISR + revalidateTag/revalidatePath — почти твоя идея: страница лежит в CDN-кэше, на miss или по тегу пересобирается в фоне. Только без полного dependency graph.
Dependency-graph caching — активно обсуждается в литературе и используется в data layers (React Query, TanStack Query, даже в некоторых ORM). Есть даже академические работы про «dependency-aware online caching».
Varnish — можно эмулировать граф через bans по тегам, но native dependency graph там нет.
IPFS + CAS — уже используется для статических сайтов и экспериментальных динамических (IPFS + edge functions).
Минусы и как их обойтиСложность построения графа для полностью пользовательских данных (сессия, A/B-тесты). Решение: базовая страница общая + персональные фрагменты как отдельные targets (тот же Russian Doll + ESI).
Storage overhead на старте. CAS решает — дубликаты не хранятся.
Latency на первом miss. Решается pre-warming + background regeneration (как в ISR).
Вывод: Да, делай. Это будет следующий шаг после ISR и Russian Doll — полноценная build-system для живого веба. Особенно на Refal получится красиво и декларативно. Если хочешь, можно начать с прототипа: Refal + IPFS для хранения + простой HTTP edge handler. Получится штука, которую потом можно продавать как «Nix для веб-страниц».Если интересно — могу набросать минимальную архитектуру или помочь с Refal-прототипом правила для страницы. Звучит как проект, который реально может выстрелить.
