[Перевод] Проблемы с JAMStack: вам может понадобиться бекенд
У отличных приложений должны быть отличные маркетинговые сайты — именно поэтому всегда стоит присматриваться к новым трендам и разработкам в системах управления контентом (CMS). Притом, что в этой нише традиционно доминируют опенсорсные гиганты, такие как WordPress и Drupal, со времен перезапуска Smashing Magazine еще в 2017 году начал возрождаться интерес к статическим сайтам.
Учитывая (порой учиненную руками разработчиков) сложность современной клиентской разработки, нас, пожалуй, не должно удивлять желание вернуться к той простоте, которую давал простой HTML — в конце концов, многие современные проблемы (производительность, асинхронные данные, кэширование, т.д.) при отказе от динамического серверного языка, либо становятся несущественными, либо превращаются в стандарт.
В то время, как сегодня есть много людей, громогласно высказывающихся в пользу современных статических сайтов, но один из крупнейших таких поборников — Маттиас Биильманн из Netlify, который и придумал JAMStack (название может показаться слегка абсурдным) и помог популяризовать потоки задач, в которых используются такие инструменты, как статические CMS и API для электронной коммерции.
Маттиас Биильманн рассказывает о JAMStack на конференции.
JAMStack стал настолько популярен, что у него даже есть собственная новостная рассылка, он породил целую экосистему плагинов, сервисов, статей и даже конференций. Так что же в нем такого особенного?
Определение JAMStack
Суть JAMStack сводится к следующему:
Это JavaScript для обработки асинхронных запросов к данным/интерактивности.
API для обработки запросов к динамическим данным/их извлечения.
Разметка, компилируемая в статические HTML-файлы.
Несмотря на то, каков был исходный акроним, все эти принципы легко и применимы к Jekyll — это допотопные блоги. Разница — в значительно улучшенном оснащении, потоках задач и экосистеме, которые развились в ответ на возродившийся интерес. Сочетая современный инструментарий Gatsby с сервисами, например, Formspree и «статической» CMS (например, с собственной CMS Netlify), JAMStack подсказывает, что статические сайты — это не только вычурные блоги разработчиков или любительские сайты, а серьезная технология, с которой можно претендовать на клиентские проекты.
Среди их ожидаемых достоинств — выигрыш в производительности, улучшенная безопасность и спасение от раздутых систем управления содержимым, к которым мы уже успели привыкнуть:
«Это новый способ создания веб-сайтов и приложений, обеспечивающий более высокую производительность, улучшенную безопасность, удешевление масштабирования и еще больше удобства для разработчика.»
Но, думаем, найдется по крайней мере несколько причин, по которым нужно поостеречься с переходом на эту инновационную технологию:
Навязанный минимализм
К сожалению, почти все преимущества статических сайтов объясняются попросту тем, какой минимализм в них навязывается. Например, производительность по показателю TTFB (время до первого байта) будет наилучшей, какой она в принципе может быть (при прочих равных), поскольку на уровне загрузки страниц не будет тех издержек, что возникают при динамической генерации содержимого. Сайт будет значительно безопаснее только благодаря тому, что на нем не используется язык серверной стороны или база данных — которые могли бы стать векторами для вторжения. Хостинг будет экономичнее, а масштабирование — бесконечно проще, поскольку также не будет предъявляться требований к языку серверной стороны или к базе данных.
Диаграмма производительности с сайта CSS Tricks, демонстрирующая повышение скорости после перехода на JAMStack.
Невозможно отрицать, что статический сайт быстрее и безопаснее динамического, а также, что он лучше поддается масштабированию –, но это все равно, что вытащить из автомобиля двигатель и объявить, что такой транспорт гораздо экономичнее. Если все эти динамические возможности были не слишком нужны, то остается спросить –, а зачем их вообще добавляли?
Действительно, лучше начинать на минималках, чем по-быстрому сделать медленный и раздутый сайт. Но хорошо сконфигурированный полностраничный кэш, использующий, например, Redis или FastCGI фактически «даром» даст вам такую же производительность, как и у статических сайтов. Даже в призыве Эрика Мейера «Get Static» (статья о том, что в условиях пандемии COVID-19 статические сайты позволили бы лучше справляться с потребностями по трафику), предлагается следующее:
Не могу подсказать вам, каким образом вам лучше всего перейти на статику — только вы сами можете с этим определиться. Может быть, для вас такая стратегия — это использовать очень агрессивное кэширование на сервере и применять сброс кэша для обновления информации.
Незрелый (но сложный) инструментарий
Притом, что с инструментарием проделано немало работы, большинство построителей статических сайтов и близко не сравнимы по гибкости с более традиционными CMS или серверными фреймворками. Элементарные возможности, в частности, именованные/псевдонимные маршруты предоставляются редко, а Netlify CMS (при всей интересности) едва ли может поспорить в удобстве редактирования с Matrix от Craft или с Flexible Content Fields от ACF. Любой, кому довелось сверх пары часов с современными предложениями из категории CMS-как-услуга, знает, насколько они уступают своим предшественникам. Им не хватает нужных возможностей по всем фронтам, от условного ввода до заполнения обязательных полей.
По иронии судьбы, именно возможности редактирования контента наиболее страдают от подхода JAMStack, поскольку, несмотря на всю увлеченность разработчиков обычным текстом, оказывается, что удивительно неудобно создавать сложный редакторский контент без помощи конфигурируемой CMS. Достаточно представить сборщик контента с переменными типами содержимого и поля связанных объектов — и оказывается, что все это исключительно сложно выразить при помощи разметки, даже такой неудобной как YAML и контринтуитивной как JSON — особенно, если речь идет о больших текстах.
Более того, если вы решите обойтись полностью без CMS и целиком вводить эту информацию на фронтенде самостоятельно (что, определенно, работает), то на вас ложится вся ответственность по запоминанию этих полей и их типов. Забудьте о проверке типов и ограничения (касающиеся, например, связанных полей/внешнего ключа), а также об условных конструкциях, предлагаемых в традиционных CMS.
Частично со всем этим можно справиться при помощи типизированных MDX-файлов, в которых можно перемежать компоненты React с разметкой, но такой подход сильно зависит от разработчика.
В результате, сложно самостоятельно сделать систему для редактирования, которая хотя бы приближалась по надежности к любой CMS, имеющейся на рынке. Это не просто проблема «редакторов-гуманитариев», но и большое неудобство для всех причастных.
Борьба с системой JAMStack
Из кейсов, исследующих JAMStack, наиболее озадачивают не те, что связаны со статическими маркетинговыми сайтами, а те, что диктуют острую потребность в динамических возможностях.
Сам Smashing Magazine требует продвинутых возможностей поиска, простейших функций интернет-магазина, многопользовательской CMS и интегрированной системы комментариев. Это детали, неотъемлемо связанные с успешностью и функциональностью бизнеса, а Smashing Magazine исключил их уже на этапе выбора стека.
Вообще-то, это ваши (как разработчика) проблемы, и вам выбирать, когда перегружать их (и перегружать ли вообще) на сторонние сервисы, но JAMStack практически не оставляет вам выбора, кроме как распределить ответственность между множеством разных (и не всегда надежных) сторонних сервисов. Примерно в том же ключе, в котором бессерверная парадигма требует полагаться на «чей-то чужой сервер», стек JAMStack обычно требует полагаться на «чей-то чужой бекенд».
Когда читаешь список зависимостей, действующих в Smashing Magazine, он напоминает сервисный эквивалент node_modules, в том числе, Algolia, GoCommerce, GoTrue, GoTell плюс разнообразные сервисы Netlify. На самом деле, исключительно ценно знать, что передавать на аутсорс (и когда), но в данном случае интересно отметить, что вся эта сложность была привнесена в ходе явных попыток «вернуться к основам». Это я еще не говорю о потенциальной хрупкости системы, которая полагается на такое огромное количество разрозненных сторонних сервисов.
Если вы можете быть уверены, что ваш проект никогда не потребует динамических серверных возможностей, то, пожалуй, стек JAMStack вам подойдет. Однако, как только вам понадобится динамическая возможность (например, заполнение форм или поддержка комментариев), вам придется либо полагаться на сторонние сервисы или самостоятельно построить отдельный API (фактически — создать бекенд). Это ничего не решает, а просто неуклюже распределяет ответственность.
Это даже не слишком вредит прогрессивному улучшению, поскольку возможности, обычно предоставляемые «даром» (например, сообщения о валидации форм) и возможности электронной коммерции требуют JavaScript, там, где ранее этот язык был не нужен. Все динамическое должно быть клиентским, то есть, придется латать все больше дыр по мере того, как дела будут ухудшаться. При этом, я даже не говорю о потенциальных проблемах с производительностью, возникающие, когда на клиенте накапливается такое множество (зачастую ненужной) логики.
Заключение
В Интернете по-прежнему остается место для статических сайтов, но эта область сужается, а не растет. Такие проекты по-прежнему встречаются в портфолио разработчиков, в особенности, если речь идет о хобби-проектах. Да, в наши дни по-прежнему можно построить поток задач, управляющий роем разрозненных сторонних сервисов, плюс поддерживать CMS, которая оснащена контролем версий, плюс ворох файлов-шаблонов, чтобы построить действующий (и при этом быстрый!) сайт, но ценность такой конструкции сомнительна. JAMStack не снижает сложность, а просто перераспределяет ее.
Безопасность и производительность — это, безусловно, серьезные факторы, которые и в дальнейшем будут доставлять проблемы разработчикам, авторам библиотек и владельцам продуктов, пока существует отрасль разработки программ. Но снижение уровня ответственности — это не решение.
Характерно, что мы обратились к простейшей форме веб-сайта — статическому HTML — и превратили его в сложный ландшафт процессов сборки, инструментов и сервисов, который готов сравниться по сложностями с теми технологиями, что он по идее должен был заменить.
