Гипотетически рассмотрим социальную фотоплатформу — каждая фотография получает свой собственный URL-адрес, эта страница содержит изображение, текст об изображении, кнопки, которые пользователь может нажимать, связанные изображения и некоторые пользовательские элементы (возможно, уведомления и т. д.). Существуют разные способы работы с фронтендом. В каждом случае элементы, характерные для вошедшего в систему пользователя, и связанные изображения извлекаются через вызовы API и отображаются на стороне клиента.
Для рендеринга остальной части страницы есть несколько различных возможностей:
SEO является приоритетом, поэтому чистый рендеринг на стороне клиента не оптимален.
Рендеринг на стороне сервера для каждой страницы с помощью NextJS или даже Express — еще один вариант.
Другой способ - сделать статический экспорт в что-то вроде NextJS, который будет генерировать отдельные файлы html для каждого изображения.
Теперь я думаю пропустить все это и вернуться к старой школе с sed/awk. У нас будет файл шаблона со всеми элементами стиля и заполнителями для URI изображения, его описания и т. д. Затем скрипт выполняет итерацию по списку значений (запрошенных из базы данных), характерных для каждого изображения (URI источника img, текст описания и т. д.) и использует sed для замены заполнителей в файле шаблона и вывода отдельного html-файла.
Каждый файл имеет один и тот же javascript для загрузки пользовательских компонентов.
Каждый раз, когда кто-то добавляет новое изображение, скрипт запускается с uri изображения, описанием и т. д., поскольку ему передаются переменные, и добавляет новый html-файл в плоскую файловую структуру.
Эти «переменные» хранятся в базе данных. Поэтому всякий раз, когда мы меняем «дизайн» страницы, мы снова повторяем тот же процесс — перегенерируем каждый html-файл.
Плоская файловая структура столкнется с ограничениями, которые можно решить с помощью структуры каталогов. Nginx остается производительным с большим количеством файлов.
Прямо сейчас мы используем NextJS с сочетанием рендеринга на стороне сервера и статических страниц, так что все хорошо. Но мне было интересно добиться чего-то подобного с более элементарными (и производительными) инструментами.
Здесь не требуется слишком много дополнительной работы — создать шаблон html-файла несложно, и это не составит труда написать сценарий.
Что в этом хорошего и плохого?
Примерно так работали некоторые веб-сайты в 90-х годах. То, что эти подходы проблематичны, не имеет ничего общего с их возрастом, а все связано с трудностью создания безопасного веб-сайта таким способом.
В частности, настоящие шаблонизаторы поддерживают некоторую степень автозавершения. Sed и awk этого не делают. Кроме того, на этих языках сложно выразить любую, кроме самой тривиальной бизнес-логики. Например, как вы будете запрашивать базу данных? Sed не может этого сделать.
Напротив, генерация статических сайтов может быть очень хорошей идеей - обслуживание статических файлов происходит очень быстро, оно хорошо масштабируется, и существует фантастическая экосистема генераторов статических сайтов. Поэтому совершенно нормально запустить какой-нибудь скрипт для генерации статических HTML-файлов, если это то, что вам нужно. Только используйте для этого настоящий шаблонизатор, пожалуйста.