JAMstack - история о том, как разрабатывать статичные сайты в 2019

JAMstack

Существует множество CMS, таких, как MODX, WordPress и т.д., которые организуют работу со всеми частями сайта, от пользовательского контента до администрирования данных на сайте. Процесс разработки сайтов в таких системах зачастую сводится к таким вещам как: верстка, установка и настройка CMS, организация взаимодействия визуальной части сайта с данными в бд и возможностью их редактировать из административной части. Такие сайты являются динамически генерируемые, тоесть на сервере происходит генерация страницы, а браузеру уже отдается готовый html файл. Но вспомните, как у вас начинался путь разработчика сайта? Редактор текста(блокнот) html, css, javascript и вот у вас уже готовая страница сайта. Судя по трендам веб разработки можно увидеть, что история циклична, и что новое это давно забытое старое в новом исполнение. Итак, сегодня хотелось бы поговорить про JAMstack и про сервисы которые появились вместе с этим подходом разработки сайтов.


Так что же такое JAMstack?


JAMstack — это отличный способ создания быстрых, безопасных и статичных веб-сайтов. Разберем аббревиатуру.

J — JavaScript.

JavaScript отвечает за загрузку всех данных на ваш сайт (а также за любое другое динамическое программирование, выполняемое на стороне клиента). JavaScript может быть в любом виде, который вы захотите! React, Vue.js… ванильный JS.

А — API.

API — это способ доступа к данным. То, что обычно находится на вашем сервере, теперь абстрагируется в виде API. В большинстве случаев ваши данные будут храниться на сторонних сервисах, известных как безголовые CMS (headless CMS), таких, как Netlify CMS Contentful, Directus, Kentico Cloud и т.д.

М — Markup(разметка).

Markup — какой-то контент-генератор или "шаблонизатор", позволяющий создать разметку страниц. Разметка имеет два общих проявления — HTML и XML. Возможно возникает вопрос: "разве не на всех сайтах есть разметка? Что делает разметку в JAMstack такой уникальной?". Дело в том, что в отличие от динамических сайтов, которые создают новую страницу HTML для каждого полученного запроса (это предполагает запрос базы данных и объединение результатов с разметкой и плагинами) — страницы JAMstack создаются во время развертывания с помощью статического генератора сайта(Static Site Generators) таких, как Jekyll, Gatsby, Hugo. Это означает, что пользователь получает контент с минимальной задержкой по запросу. Это позволяет сделать сайт не только быстрыми, но и делает его гораздо более безопасными из-за отсутствия запроса к базе данных.

Для чего этим нужно пользоваться?


Существует множество статей о том, почему JAMstack хорош, и, в конце концов, он сводится к 4 моментам: веб-сайты, построенные с использованием этой архитектуры, быстрее, безопаснее, масштабируются лучше и являются модульными. Также стоит учесть, что для публикации сайта в интернете с помощью подхода JAMstack не нужно затрачиваться на хостинге и домене(если вас устроит домен третьего уровня).

Как сделать сайт, используя JAMstack?


В данном примере разработаем блог, для этого нам понадобится:
Дальнейший процесс я показываю для операционной системы Ubuntu 18.04, но если вы хотите проделать всё тоже самое, с комфортом, в Windows 10, то думаю вам пригодится статья на моем сайте: Используем подсистему Linux (WSL) в Windows 10 для разработки сайтов.
Начнем разработку сайта с создания контента и генерации сайта, для этого нам поможет Hugo.
Hugo — простой и быстрый генератор статических сайтов написанный на языке Go.

Установка Hugo

Hugo не требует внешних зависимостей и устанавливается в системе как независимое приложение. Hugo сверхбыстрый. Сборка сайта с 10к страницами занимает менее секунды, что очень радует.

Обновляем программные пакеты
sudo apt-get update


Устанавливаем Hugo с помощью snap менеджера пакетов (если вы используете более старую версию убунты, то вам дополнительно нужно будет установить пакетный менеджер snap).
sudo snap install hugo


Проверяем версию:
hugo version


Создаем блог

Для примера, создадим новый сайт в директории ~/projects, вы можете использовать другую директорию(в WSL Windows 10 можно хранить свои проекты например в папке projects находящейся в корне диска С, тогда путь к ней будет иметь вид /mnt/c/projects).

Если такой директории еще нет, то создаем:
mkdir ~/projects


Перейдем в директорию:
cd ~/projects


Команда hugo new site создает новый сайт. Выполняем:
hugo new site test-blog


В нашем случае генератор Hugo создал сайт в папке ~/projects/test-blog. Перейдем в нее и посмотрим какие директории там создались:
cd ~/projects/test-blog
ls


Получим такую структуру:
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes


config.toml — файл с настройками нашего сайта
themes — предназначена для размещения тем.
content — служит для хранения страниц сайта.

Фундамент нашего блога готов. Теперь добавим тему.

Для Hugo существует множество бесплатных шаблонов. Можно также создать и собственную тему, но не сегодня 😉. Переходим на официальную страницу со списком тем и выбираем понравившуюся тему, например therminal копируем ссылку, которая находится в Download и клонируем тему
git clone https://github.com/panr/hugo-theme-terminal.git themes/terminal


Теперь настроим наш сайт и применим тему.

Редактируем config.toml
nano config.toml


И изменим настройки чтобы они имели следующий вид:
baseurl = "/"
defaultContentLanguage = "ru"
languageCode = "ru-ru"
theme = "terminal"
paginate = 5

[params]
  contentTypeName = "post"
  themeColor = "orange"
  showMenuItems = 2
  fullWidthTheme = false
  centerTheme = false

[languages]
  [languages.ru]
    title = "Наш тестовый блог"
    subtitle = "Вот так и сделали блог на Hugo"
    keywords = ""
    copyright = ""
    menuMore = "Показать больше"
    readMore = "Подробнее"
    readOtherPosts = "Просмотреть другие статьи"

    [languages.ru.params.logo]
        logoText = "Наш тестовый блог"
        logoHomeLink = "/"

    [languages.ru.menu]
        [[languages.ru.menu.main]]
            identifier = "about"
            name = "Обо мне"
            url = "/about"
Сохраняем настройки и выходим из редактора.
Более подробно о настройках каждой темы можно прочитать на ее домашней странице.
Для создания страниц и постов, в Hugo используется команда hugo new.

Для начала нам необходимо создать страницу "Обо мне". Выполняем в корневой директории нашего сайта:
hugo new about.md


Данная страница находится в директории contents

Hugo имеет одинаковую структура на всех страницах. В пространстве между разделителями --- располагается информация о странице, а ниже уже содержание страницы в формате Markdown.

Приведем страницу "Обо мне" к следующему виду:
---
title: "Обо мне"
date: 2019-08-07T12:56:15+04:00
---

### И так, кто я такой?

Веб-специалист — универсальный специалист, соединяющий в себе несколько профессий. Основные задачи - разработка, оптимизация, сопровождение и контроль над качеством в различных веб-процессах. К ним относятся следующие специалисты:

- веб-дизайнер
- веб-разработчик
- веб-мастер
- веб-верстальщик
- веб-архитектор


Страницу о себе мы создали, теперь создадим наш первый пост.
hugo new post/first-post.md


В нее добавим следующее
---
title: "Первая статья"
date: 2019-08-07T13:01:31+04:00
description: "Здесь некий текст превью......."
---

Веб-разработка — процесс создания веб-сайта или веб-приложения. Основными этапами процесса являются веб-дизайн, вёрстка страниц, программирование для веба на стороне клиента и сервера, а также конфигурирование веб-сервера.

Теперь можем запустить наш сайт и посмотреть, как это всё будет выглядеть
hugo server --bind=0.0.0.0 --port=1313


Открываем в браузере наш сервер по адресу http://localhost:1313/ и видим главную страницу нашего блога:

главная страница localhost:1313

Разработка примера сайта завершена.
Теперь перейдем к размещению блога в интернете.

Размещаем сайт в интернете


Для этого нам понадобится Netlify, авторизовываемся на этом сайте и у нас теперь есть два путя =)

Первый путь

Генерируем сайт с помощью команды
hugo


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


Второй путь

  • Загружаем директорию с сайтом на github
  • Синхронизируем github с netlify
  • Выбираем репозиторий на котором располагается наш сайт и вводим команду для генерации сайта hugo, далее netlify сам подцепит сгенерированную директорию и выведет готовый сайт.
  • Далее можно настроить в netlify свой домен, и настроить отправку с формы через встроенный сервис.
Для редактирования контента можно использовать Netlify CMS, либо редактировать исходные данные как в части создания сайта(если интересна данная тема, то можно рассмотреть в отдельной статье).
В отличие от того же github pages с помощью netlify можно генерировать сайты с приватных репозиториев github.

Также приведу некоторые конфигурации, в которых вы можете использовать JAMstack:
  • Gatsby JS (SSG — статический генератор сайтов) + Contentive (безголовая CMS) + Netlify (CDN, на котором размещен сайт распределенным образом)
  • Jekyll (SSG) + Github страницы (для хостинга)
  • Middleman (SSG) + S3 (простой сервис хранения) + Netlify


Заключение


Данная статья была написана под вдохновением статьи Nuxt.js — введение и здесь я хотел рассказать про подход отличающийся от привычного процесса разработки сайтов, а также рассказать про сервис Netlify, который я использую чаще всего для показа верстки заказчику =)
Всем спасибо за внимание!
Фух… Наконец-то написал свою первую статью для modx.pro 😁
Алексей Соин
07 августа 2019, 12:51
modx.pro
3
537
+22
Поблагодарить автора Отправить деньги

Комментарии: 24

Это сообщение было удалено
    Это сообщение было удалено
Станислав
07 августа 2019, 13:35
+1
Крутая статья!
Огромное спасибо автору!!!
srs
srs
07 августа 2019, 13:52
+5
Похоже это начало становления modx.pro более технологически полиморфным. Что не может не радовать.
    Николай
    07 августа 2019, 14:55
    0
    В конце концов может и на MODX отразится, глядя на разнообразие подходов к разработке. Невольно смотришь на всё это и думаешь, а как в MODX что-то похожее впендюрить? =)
Николай Савин
07 августа 2019, 15:38
0
Не в коем случае не хочу задеть автора статьи. Я скорее хочу написать свое мнение о желании писать здесь статьи не связанные с MODX.

Ох боюсь я что если отойти от темы сообщества — то сайт может превратиться в информационную помойку. Авторский материал то может и полезный, и актуальный для web в целом. Но сильно разный, не понятно по какому признаку относящийся к проекту и зачем здесь нужный.

Предлагаю фильтровать материал все таки как то по отношению к MODX. К примеру статьи про фронтэнд, который взаимодействует с бэкэндом на MODX — это наверное уместно, если описана технология и методика связи фреймворков.
    Алексей Соин
    07 августа 2019, 15:53
    +5
    Я был готов к такому комментарию 😅. Лично я считаю, что увеличение кругозора и списка известных технологий помогают разработчику более профессионально использовать свои навыки в проектах. Например в данной статье я рассказывал про такой сервис как Netlify, которым, если рассматривать в ключе MODX, очень удобно пользоваться для показа верстки заказчику и последующей интеграции её с MODX, ведь с этим сервисом очень хорошо экономиться время на размещении верстки. Или например когда я переносил свой блог с MODX на GRAV CMS я увидел весь кайф в работе с yaml файлами и тем, как php работает с ним, и вот теперь везде где это уместно, при разработке сайтов на MODX или на какой то другой системе, я использую yaml файл вместо json файлов, как это было у меня ранее)))

    А помойкой сайт modx.pro точно не станет, если учесть как часто на сайте выходят новые статьи увеличение тем только пойдут на пользу.
      Николай Савин
      07 августа 2019, 17:00
      0
      Увеличение кругозора это оптимальное вложение денег, времени и сил. Согласен на 100%. Главное делать это последовательно и применять на практике. Я вот кстати даже не знал о существовании подобных инструментов. За что спасибо.
      Дальше сарказм.
      Теперь у меня будет больше ненужной информации в голове )) Пока не представляю где это применить.
      Николай Савин
      07 августа 2019, 17:03
      0
      Кстати визуальное представление (а прочел я статью по диагонали) здорово смахивает на октябрь.
      Я вот не понял. Если информация не хранится в базе, то как она хранится? В одном структурированном файле или каждая статья отдельным файлом?
        Алексей Соин
        08 августа 2019, 07:36
        0
        Если как в данном случае использовать генератор статических сайтов Hugo, то ресурсы (то есть исходники страниц сайта) хранятся в папке content и имеет вот такую структуру
        ├── _index.md
        ├── about.md
        └── post
            ├── _index.md
            ├── post-1.md
            ├── post-2.md
            └── post-3.md
        А если использовать такую безголовую CMS как strapi, то в ней хранятся данные в файле SQL lite
    srs
    srs
    07 августа 2019, 17:13
    0
    Главное что Василий не против.
      Николай Савин
      07 августа 2019, 17:19
      0
      Так и я не против (Как будто это кого-то волнует). Лишь бы не распылить внимание аудитории, ожидающей (прежде всего) статей хотя бы отдаленно связанных с MODX.
    Fi1osof
    07 августа 2019, 23:00
    +1
    Николай, разработка сайта в целом — это бэк и фронт. MODX — это только бэк. А по фронту здесь мало информации. Получается, делаешь сайт на MODX, на сервере все ОК, а фронт — как будто школьник учится. По фронту информация нужна однозначно. А фильтроваться будет само — кому не интересно, тот пропускает. А тратить свои калории и писать часто что-то не интересно — не каждый станет. И по большому счету львиная часть топиков здесь — это вопросы из серии «как мне вставить чекбокс?». И что теперь? Сказать им «Не пишите такие статьи, они бесполезные, пишите только очень интересные и полезные статьи»? Вот такая статья стоит десятков среднестатистических заметок здесь.
Fi1osof
07 августа 2019, 23:07
+3
Это позволяет сделать сайт не только быстрыми, но и делает его гораздо более безопасными из-за отсутствия запроса к базе данных.
Здесь, конечно, слукавил немного. Какая разница в какой момент происходит обращение к базе данных (в момент серверного рендеринга или потом по API)? В любом случае есть тонкий клиент к БД (окно). При чем вот в таком современно формате это окно более открытое и опасное, потому что в классическом варианте бОльшую часть из БД можно получать не давая пользователю доступ к этим запросам (то есть извне не вызвать просто так, можно только страницу вызвать). А в случае с JAM используется более обширное API, позволяющее получить практически всю информацию (иначе она не подтянется и просто не отобразится на сайте). Так что где безопасней, это еще бабка надвое сказала.
    Алексей Соин
    08 августа 2019, 07:57
    +1
    Тут тогда сразу возникает вопрос, а какие данные не могут быть сгенерированны один раз в html файл и их нужно брать из бд по API? Страницы с контентом вполне можно собрать один раз в виде html файлов и никаких обращений к бд не потребуются. А если нужна, например, форма обратной связи, то у самого сервиса Netlify есть api для этого или можно воспользоваться вот таким сервисом. Если нужны комментарии на сайте, то подключаем disqus. Это конечно как вариант, можно конечно всё своё использовать для формы обратной связи и комментариев.

    А тем текстом, который приведен в цитате, я хотел сказать, что статичные сайты получают такое преимущество, как исключения взлома с помощью sql инъекций(возможно даже ddos, но тут я не уверен). И тут еще такой момент возникает, эти динамичные запросы которые будут в статичном сайте с большой долей вероятности будут и на динамическом сайте, и они будут работать по тому же принципу, следовательно дыр безопасности будет меньше на статичном сайте.

    Николай, насколько я знаю, в вашей cms используется как раз rest api для работы с данными, исходя и накопленного опыта можешь рассказать, какие есть проблемы в безопасности при работе с rest api(или там graphQL используется… я уже точно не помню)?
      Fi1osof
      08 августа 2019, 08:04
      0
      Если комменты disqus, обратная связь Netlify и т.д. и т.п., то это уже практически полностью статический html-сайт без большинства современных прелестей. Но в таком случае да, он действительно будет безопасен :)

      Николай, насколько я знаю, в вашей cms используется как раз rest api для работы с данными, исходя и накопленного опыта можешь рассказать, какие есть проблемы в безопасности при работе с rest api?
      Нет, REST я не использую категорически. Что использую, описал здесь: modx.pro/development/18708

      Про безопасность в GraphQL — отдельная тема. Тем действительно есть моменты и очень серьезные, но пока про это рано. Расскажу позже, когда народ освоит хотя бы базис.

      Про безопасность в REST ничего не скажу, не моя область.
        Алексей Соин
        08 августа 2019, 08:16
        +1
        Если комменты disqus, обратная связь Netlify и т.д. и т.п., то это уже практически полностью статический html-сайт без большинства современных прелестей.
        Ну судя по документациям в работе с JAM-стеком в большинстве случаев предлагают именно так делать. Думаю у многих было такое, что разрабатывал лет 5 назад небольшой сайт на modx кому то, он прекрасно работал, и тут бац, пошли массовые взломы всех версий modx до 2.6.7 версии и этот сайт перестает работать, данные затерлись, в общем ужас… Мелкий сайт, а получаем большие проблемы, данные восстановить, modx обновить, проверить что всё работает и т.д. Хотя для заказчика этот сайт нужен был для статей и как визитка организации. Используя статически генерируемые сайты эта проблема просто не могла бы возникнуть, и если бы уж и как то получилось так, что с сайтом что то случилось, то используя версионирование github можно просто откатиться на стабильную версию и посмотреть в чем проблема.

        Про безопасность в GraphQL — отдельная тема.
        Интересно было бы почитать =)
          Fi1osof
          08 августа 2019, 08:19
          +1
          В целом согласен. Но этот тренд еще не в конце пути, так что нас ждут еще новые вариации и новые виды взлома (как то «github взломали, сотни тысяч сайтов оказались заражены»).
            Алексей Соин
            08 августа 2019, 08:26
            0
            Да, согласен, JAM-стек достаточно молодое направление, а началось всё с jekyll и тем, что github его из коробки у себя стал поддерживать =)
Anton Erin
08 августа 2019, 17:52
+1
Ребята, что вы делаете? :)
Вот же всё готовое есть, работает отлично! Всё гораздо проще и с таким же эффектом.
Перенос сайта еще проще — тупо скопируй директорию. Всё.

Grav CMS.
learn.getgrav.org/16/content/content-pages
    Fi1osof
    09 августа 2019, 01:13
    +1
    Requirements
    PHP 7.1.3 or higher. Check the required modules list
    Check the Apache or IIS requirements

    Чот падазрительна. Это точно можно будет потом на github.io вылить и оно будет работать там как статический сайт?
    Алексей Соин
    09 августа 2019, 12:21
    0
    Grav CMS — это представитель так называемых Flat-FIle CMS (October CMS кстати тоже к такой относится), хорошая система, у меня даже по ней статейка есть))) но это не в коем случае не JAMstack.
Александр Мельник
08 августа 2019, 18:13
+2
Сразу признаюсь, что совершенно ничего не понимаю в этих современных технологиях.
Мне кажется это так странно, что люди на полном серьезе рассуждают что для того чтобы создать статичный сайт нужно устанавливать через консоль стороннее приложение, писать содержимое в формате markdown, компилировать его… Чем старый добрый html хуже?
    Fi1osof
    09 августа 2019, 01:24
    +1
    писать содержимое в формате markdown, компилировать его… Чем старый добрый html хуже?
    Ну, к примеру, тут, когда мы пишем комментарии, на сервере, прежде чем сохраниться, они обрабатываются джевиксом. А если этого не делать, то что произойдет? Правильно.
    <a href="#" onclick="alert('hacked')">click me</a>
    С маркдауном этой проблемы нет (вроде как) и можно сохранять и выводить как есть.

    В случае рендеринга реактом тоже нет это проблемы, потому что реакт не принимает простые строчные значения для хендлеров, ему надо писать именно с передачей функции.
    <a href="#" onClick={() => {alert('secure message')}}></a>
    У меня вот такое вообще оформление используется: front-editor.prisma-cms.com/topics/individualnoe-oformlenie-kazhdogo-topika-v-otdelnosti.html
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
24