Введение в Jamstack: создание безопасных высокопроизводительных сайтов

Время от времени веб-разработка резко меняется к лучшему. В этой статье мы познакомим вас с Jamstack, объяснив, что это такое и почему он хорош.
В свое время динамические сайты взорвались стеком LAMP. Затем стек MEAN стал основой для следующего поколения веб-приложений. Теперь, когда растет число API-интерфейсов и повторно используемых компонентов, статические сайты снова в моде. Это своего рода «возвращение к истокам», но не совсем.

Что такое Jamstack?

Jamstack является переопределением современной сети для более быстрых и более безопасных веб — сайтов . Эти сайты лучше масштабируются, и при правильном наборе инструментов их намного проще (и веселее) разрабатывать и поддерживать.

Разберем термин:

• J обозначает JavaScript . JS прошел долгий путь с тех пор, как был представлен Netscape в 1995 году. С помощью реактивных и прогрессивных библиотек вы можете разрабатывать веб-приложения, которые ведут себя во многом как мобильные.
• A означает API . Вам не нужно самостоятельно программировать каждую функцию, но вы можете полагаться на стороннюю обработку для огромного количества задач.
• M означает разметку . Вы можете повторно использовать уже разработанные компоненты или создавать новые, которые намного проще поддерживать.

В каком-то смысле да. Термин Jamstack , первоначально стилизованный под JAMstack, был придуман компанией Netlify как способ продвижения своей » универсальной платформы для автоматизации современных веб-проектов«. Принципы, лежащие в основе Jamstack, на самом деле не новы, поскольку веб-компоненты и API существуют уже довольно давно.
Но почти таким же образом термин Ajax (асинхронный JavaScript и XML) был придуман другой компанией в свое время — Adaptive Path — и хотя API XMLHttpRequest (XHR), который сделал Ajax возможным, также существовал некоторое время, оба Ajax и JAMstack были освежающим обновлением идей с законным использованием, которые были быстро приняты сообществом. Шумиха заслужена: такой способ работы стал откровением для многих разработчиков по всему миру.

Статические сайты

«Статические сайты» — это полная противоположность «динамическим сайтам», верно? Итак, как обеспечить богатое и динамическое взаимодействие с простыми файлами HTML? Ну, JavaScript.

JavaScript развивалась много , так как первые войны браузеров , закрепив себя как язык программирования общего назначения с появлением Node.js , и библиотеками React , угловой и Vue.js . Возможности для разработки полноценного пользовательского интерфейса (UI) безграничны.

Конечно, JavaScript — не серебряная пуля. Скорее всего, вы не будете заниматься с ним анализом данных или искусственным интеллектом. Но для веб-разработки вряд ли есть что-то, что нельзя сделать с API, который можно использовать с помощью методов JavaScript, поскольку есть вероятность, что кто-то уже создал для него микросервис.

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

Вот и стек J · A · M: JavaScript, API, разметка.

Развязка, без головы, микросервисы, без сервера… Извините, что?

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

Coupled, Decoupled, Headless

СВЯЗАННЫЙ — это когда контент веб-сайта создается, управляется и хранится на серверной части сайта, где находится база данных (например, администратор WordPress). Затем этот контент извлекается из серверной части и представляется в браузере через интерфейсный интерфейс (например, шаблон WordPress). В некотором смысле «связанное» приложение — это традиционный «полный стек», в котором внутренняя и внешняя части являются разными сторонами одного и того же приложения.

Напротив, ОТКЛЮЧЕНИЕ — это когда серверная часть и клиентская часть управляются отдельно — это означает, что база данных и инструменты управления будут находиться на одном сервере, а интерфейсная часть — где-то еще . Естественно, должен быть носитель, с помощью которого оба соединяются, обычно это API. Более того, поскольку серверная часть теперь эффективно отделена от передней части, на самом деле может быть несколько внешних интерфейсов в разных местах! (Подумайте о разных витринах, использующих один и тот же движок, например Shopify.)

Короче говоря, у ПО HEADLESS просто нет интерфейса или уровня представления . Например, безголовая CMS может генерировать статический контент и отправлять его куда угодно: мобильное приложение, устройство Интернета вещей, статический веб-сайт. По общему признанию, это тоже «несвязанная» ситуация, но здесь вам может даже не понадобиться API. Подумайте о движке WordPress, который экспортировал свои сообщения для обслуживания в виде статических файлов HTML: это безголовый. Фактически, вы находитесь на странице, которая была создана именно таким образом прямо сейчас.

Монолитные (сильносвязанные) и микросервисы (слабосвязанные)

Проще говоря, МОНОЛИТИЧЕСКИЙ можно определить как программное обеспечение, построенное из одного элемента . Примеры могут включать мобильное приложение, большинство приложений, которые вы можете установить на свой компьютер, и веб-приложения, такие как WordPress. Эти приложения могут по-прежнему иметь внутренние «модули» или «компоненты», но мы говорим, что они тесно связаны, потому что они являются неотъемлемой частью приложения, без которой приложение не работало бы.

С другой стороны, СЛАБО СВЯЗАННЫЕ программные компоненты работают больше как плагины, которые можно удалить или заменить , и, возможно, функциональность изменится, но ядро приложения по-прежнему будет работать. Этот принцип позволяет «аутсорсинг» функций через сторонние API — часто называемые «микросервисами» — поскольку они предоставляют вторичные функции (изменение размера изображения, вход в систему, хранение), которые сами по себе не являются неотъемлемой частью приложения.

Бессерверные и традиционные вычисления

По общему признанию, термин » бессерверный » употребляется неправильно. В каком бы компьютерном предприятии вы ни участвовали, в нем будут задействованы серверы. Но способы доступа к серверам и управления ими могут радикально отличаться.

В ТРАДИЦИОННОЙ МОДЕЛИ у вас может быть реальный физический сервер (иногда называемый » голым железом» ) или виртуальный частный сервер, ресурсы которого выделяются для вас — среди других пользователей — на физическом сервере. Ресурсы ограничены, и, независимо от того, используете ли вы их 100% или нет, вы платите за них, как если бы вы их использовали.

В БЕССЕРВЕРНОЙ МОДЕЛИ существует огромный пул ресурсов, предлагаемый многими серверами, все подключенными друг к другу. Вы можете просто тянуть то, что вам нужно, когда вам это нужно, и масштабировать (вверх и вниз) по запросу. Вы не можете точно определить какой-либо физический сервер как ваш — все, что вы знаете, это то, что ресурсы есть независимо от того, откуда они берутся.

Традиционная модель	Бессерверная модель
Физические серверы с ограниченными ресурсами	Пул неограниченных ресурсов
Склонен к сбоям (например, выход из строя жесткого диска)	Более надежная архитектура *
Ограниченная масштабируемость	Неограниченная масштабируемость
Платите за все, включая неработающие услуги	Платите за то, чем пользуетесь (платите по мере использования)
Простота использования	Необходимо изучить реализацию

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

Практические примеры Jamstack

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

Пример 1: превращение WordPress в статический сайт для 10-кратного увеличения скорости

Если статический подход — лучший вариант, что может быть лучше, чем взять динамический блог WordPress (WP) и превратить его в статический? Поступая таким образом, мы снизим скорость загрузки страницы и задержки по меньшей мере , один фактор, сильно повысить безопасность и улучшить SEO в то время как у него.

Вкратце о процессе

1. Используйте генератор статических сайтов (SSG) для создания сообщений и страниц из WP, но в статическом формате (текст, Markdown, HTML).
2. Синхронизируйте статический контент с репозиторием на GitHub, GitLab или Bitbucket.
3. Автоматизируйте конвейер развертывания, чтобы при каждом изменении в репозитории изменения мгновенно передавались в глобальный CDN.
4. Расслабьтесь и наслаждайтесь бесплатным хостингом для безопасных и быстрых веб-сайтов с автоматическим развертыванием.Конечно, это вызывает много вопросов:

• А что с админом?
• А как насчет категорий и RSS-канала?
• Как мне теперь управлять контентом?
• Как насчет разделов комментариев и информационного бюллетеня?

На этом этапе вы можете попрощаться с WP Admin. Так как с этого момента вы будете генерировать контент с помощью SSG. Фактически, SSG, такие как Jekyll , специально разработаны для создания блогов, а SSG, такие как Gatsby.js, уже поставляются со всеми включенными батареями.

Управление контентом (например, изменение существующих сообщений) — вот где на помощь приходит безголовая CMS. Для комментариев и информационных бюллетеней, разве вы еще не используете для них внешний API, такой как Disqus и Mailchimp?

Как вы на самом деле это делаете?

Мы не можем здесь описывать тонкости SSG и безголовых CMS, но следите за обновлениями для будущих выпусков этой серии. Мы представим пошаговое руководство по миграции сайта WordPress.

Пример 2: бесплатный хостинг статических сайтов с помощью автоматизированного конвейера

«Бесплатно» вы часто будете слышать в сообществе Jamstack — и, к счастью, это не бесплатно, поскольку вам все равно придется бесплатно сообщить нам номер своей кредитной карты .

Вкратце о процессе

В этом случае мы возьмем наш статический сайт (например, блог, который мы перенесли в примере 1) и разместим его в Интернете:

1. Установите репозиторий GitHub, GitLab или Bitbucket.
2. Разверните на Netlify , GitLab Pages или GitHub Pages .

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

Почему компании делают это бесплатно?

Накладные расходы на перетаскивание HTML-файлов на уже развернутую CDN минимальны. Помните, что здесь не задействованы никакие вычисления или рендеринг PHP. Если вы не хозяйничать в широком масштабе популярного сайта , который съедает много трафика, компании не против выдачи какого — то хостинга. И это может стать для них хорошей рекламой.

Раздавая много бесплатных подарков, компании также запирают вас. К тому времени, когда вам понадобится услуга премиум-класса, вы уже будете с ними. Это справедливо — и, кроме того, в тот момент вам уже нужно было либо разработать специальное решение вашей проблемы, либо все равно заплатить за услугу.

Как вы на самом деле это делаете?

Оба случая, Netlify или GitHub / GitLab, очень просты и требуют минимальных усилий. (Тем не менее, мы подробно рассмотрим этот процесс в следующей статье.)

Чем отличается Jamstack от разработки полного стека

Давайте посмотрим, как этот новый подход сравнивается со стеком LAMP или MEAN :

Стек LAMP / MEAN	Jamstack
Веб-серверы, на которых запущены сайты	Глобальные развертывания в CDN
Загрузка по FTP / SSH, перезапуск сервера	Автоматизированные трубопроводы
Страницы, отображаемые во время выполнения	Страницы предварительно обработаны для ускорения
Монолитные приложения (например, WordPress)	API-интерфейсы и микросервисы (разделение внешнего и внутреннего интерфейса)
Полный стек (языки интерфейса и серверной части)	Единый стек («JavaScript везде»)

Что еще можно сделать с Jamstack?

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

Вот еще несколько примеров того, что вы можете делать с Jamstack:

• реализация бессерверной базы данных со статическим сайтом
• идентификация как услуга (IDaaS): аутентификация без сохранения состояния
• безголовые системы управления контентом
• использование бессерверных функций на статических сайтах
• управление многоцелевыми формами
• обрабатывать многоплатформенные уведомления
• безголовые тележки для покупок
• реактивный поиск

Заключение

Развитие событий неизбежно, особенно в сфере информационных технологий. Раньше это был стек LAMP, а затем был стек MEAN. Теперь это Jamstack, а через пять-десять лет это будет что-то еще. Лучше принять эти изменения и сделать их своими!
Изучение новых способов ведения дел может показаться хлопотным, но также может оживить ваше стремление к развитию. Вы можете обнаружить, что тратите меньше времени на обслуживание серверов и беспокоитесь о проблемах безопасности. Вы можете обнаружить, что разработка требует меньше усилий, а ваши клиенты более довольны. И в результате вы можете даже стать более конкурентоспособным (и иметь возможность просить о повышении).