Комментарии 39
Как аналог для создания блогов сгодится, но полноценный e-commerce на JAMstack не сделаешь
JAMstack – это современная архитектура (архитектурный паттерн) веб-разработки, основанная на клиентском JavaScript, повторно используемых API и предварительно созданной разметке.
Выделение мое. Теперь сравним:
JAM Stack работает иначе, точнее гораздо проще.
- Пользователь запрашивает страницу.
- HTML-файл уже лежит готовенький и только и ждёт этого запроса. Ответ следует моментально.
- Для обновления контента используется Git или Headless CMS.
- Сайт автоматически пересобирается с помощью генератора статических сайтов или самостоятельно настроенной системы сборки.
Где тут API?
Апи нужно для того что бы сгенерировать статичную страницу. То есть при генерации статической страницы, у нас есть сама разметка и динамическая часть. Как пример статья, разметка одна и таже, но вот сам текст другой. Апи как раз нам позволяет вытянуть из базы (или другого истоячника ) нужную информации и сгенерировать статическую информацию.
Тогда почему на картинке в статье в какие-то там "services" ходит клиент? На всякий случай процитирую с jamstack.org:
It enables a composable architecture for the web where custom logic and 3rd party services are consumed through APIs.
Что-то это плохо сочетается с вашим "апи нужно чтобы сгенерировать статику".
если вы обратили внимание то сервис имеет пунктирную линию. и это использование либо для интерактива, как пример написание отзыва или оплата товара( эти действия же должны как-то попасть в бд) либо для генерации статики.
Тогда ваше утверждение
Сайт Jamstack представляет собой статический HTML. Нет сервера, нет базы данных, нет слабых мест
ошибочно.
Задам свой вопрос иначе: что отличает Jamstack от обычного статического сайта?
(если что, я генерил статические сайты из БД, чтобы на хостинге не было никакой динамики, еще в конце 90-ых)
В конце 90 вы делали его как?? Руками создавали дубли?? Хардкодили меняющийся текст? Jamstack автоматически генерирует страницы согласно шаблону, и без участия бэка ( точнее представления его в классическом виде? . Так же хотел бы спросить а какие вы технологии использовали в 90 - php или java?
В конце 90 вы делали его как?? Руками создавали дубли?? Хардкодили меняющийся текст?
Да нет, программу написал.
Jamstack автоматически генерирует страницы согласно шаблону, и без участия бэка ( точнее представления его в классическом виде?
И вы думаете, что это что-то новое? Вы про mail merge слышали?
Так же хотел бы спросить а какие вы технологии использовали в 90 — php или java?
Разные варианты VBA/VBScript я для этого использовал, а потом JScript (не путайте с Javascript).
Нет веб -сервера, то есть не происходит исполнения. вы просто можете у себя на пк открыть .html файл и гулять по всему сайту как вам вздумается и тестировать весь функционал, без поднимания какого-то денвера или опен сервера.
вы просто можете у себя на пк открыть .html файл и гулять по всему сайту как вам вздумается и тестировать весь функционал, без поднимания какого-то денвера или опен сервера.
Это приблизительно до первой ссылки на /.
если у вас все правильно сделано то у вас не будет такого пути
Т.е. каждая страница, как бы глубоко она ни была, зачем-то при ссылках использует ..?
(это мы еще не вдаемся в то, что говорят есть разница в выполнении JS из локальных файлов и с сайта, всякие там политики безопасности)
Т.е. каждая страница, как бы глубоко она ни была, зачем-то при ссылках использует ..?
Все страницы сразу сгенерированы и в виде файлов лежат на хосте. Все пути захардкожены .
Что насчет CORS это настройки и они легко меняются. А исполнение JS не мешает вы же подключали хоть раз jquery c помощью CDN. У вас на это ругалась система?
Все страницы сразу сгенерированы и в виде файлов лежат на хосте. Все пути захардкожены.
Захардкожены относительно чего?
Что насчет CORS это настройки и они легко меняются.
Настройки чего? Легко меняются где?
А исполнение JS не мешает вы же подключали хоть раз jquery c помощью CDN. У вас на это ругалась система?
Гм, я подключал что-нибудь с помощью CDN в сайт, а не в локальный файл. А я говорю про то, как себя браузеры могут вести с локальными файлами.
Захардкожены - относительно корня, хотя вы можете изменить эту настройку и они у вас будут валяться на одном уровне
Настройки хостинга, Браузера. если конечно в гугле не заблочены.
Попробуйте подключить в локальных файлах, при наличии интернета поведение не измениться.
Захардкожены — относительно корня, хотя вы можете изменить эту настройку и они у вас будут валяться на одном уровне
Эмм, но / — это и есть путь относительно корня. Вас не смущает, что локально и на вебсайте корень в разном месте?
Настройки хостинга, Браузера
Стоп-стоп-стоп, а зачем мне вдруг менять настройки хостинга, чтобы локально простестировать сайт?
Ну и повторюсь, пока вы описываете самый обычный статический сайт, который кто-то генерит отдельной программой. Это и называется Jamstack?..
Еще раз / работает и на локальной машине. просто при генерации чаще всего получается вот так /index.html.
Локально менять не надо, вы задали вопрос о том что как будет реагировать браузер на локальные файлы. я вам ответил точно так же как и на обычном хостинге. Далее вы сказали что безопасность и прочее. Я вам ответил что если у вас что-то тянуться с вашего хостинга или допустим вы локально хотите закинуть отзыв на товар в Headless CMS ( положить в БД) которая у вас развернута где-то на стороне. И только тогда могут быть проблемы с CORS о которых вы сказали и тогда что бы избежать боли надо немного поменять настройки.
Надеюсь теперь я объяснил понятно
Еще раз / работает и на локальной машине. просто при генерации чаще всего получается вот так /index.html.
… и куда он ведет, когда я открываю c:\temp\my site\contact.html?
вы задали вопрос о том что как будет реагировать браузер на локальные файлы. я вам ответил точно так же как и на обычном хостинге.
Ну вот это утверждение и неверно.
допустим вы локально хотите закинуть отзыв на товар в Headless CMS ( положить в БД) которая у вас развернута где-то на стороне.
Так вроде бы для Jamstack не надо ничего разворачивать "на стороне"? Я запутался.
И только тогда могут быть проблемы с CORS о которых вы сказали
Я, заметим, не упоминал CORS, это вы про него сказали.
это архитектурный паттерн, который использует CDN, Headless CMS и SSG ? При этом все манипуляции происходят на JS. На локальной машине или в GIthub.
это архитектурный паттерн, который использует CDN, Headless CMS и SSG
То есть если нет CDN, то уже не Jamstack?
При этом все манипуляции происходят на JS
То есть если генератор написан на Go, то это уже не Jamstack?
То есть если нет CDN, то уже не Jamstack? просто - так работает быстрее
То есть если генератор написан на Go, то это уже не Jamstack? - Jamstack. Но вы говорите только про SSG который может быть написан на чем угодно
Я настоятельно вам рекомендую посетить официальны сайт после посещения которого у вас снимутся множество вопросов.
просто — так работает быстрее
Так все-таки, если CDN нет — это Jamstack или нет?
То есть если генератор написан на Go, то это уже не Jamstack? — Jamstack.
Получается, что утверждение "все манипуляции происходят на JS" — тоже неверно.
Тогда что же остается от вашего "архитектурного паттерна"?
Повторюсь, вот я в начале своей карьеры генерил сайты на основании данных, которые лежали в Access, где в Access был UI (благо, тогда это легко рисовалось). Access выступал, в современной терминологии, Headless CMS. По нажатию кнопки получался полностью статический сайт (с немножечко какого-то скрипта, уже не помню, чтобы менюшки красиво разворачивались), который можно было развернуть где угодно, на любом статическом хостинге.
Это Jamstack или нет?
Но вы говорите только про SSG который может быть написан на чем угодно
А какие еще манипуляции, кроме SSG, могут происходить "на локальной машине или в Github"?
Я настоятельно вам рекомендую посетить официальны сайт после посещения которого у вас снимутся множество вопросов.
В том-то и дело, что ваши слова с ним плохо сочетаются (я даже выше уже цитировал, в чем конкретно).
Эх. сочувствую вашему травмирующему опыту в 90. Сейчас немного подругому. это все равно что говорить что у всех инструментов у которых есть струны это гитары... Но мы то свами знаем что это не так.
1) CDN - это всего лишь способ быстрого доставки нужной (статической информации) до клиента. Например туже цель преследует HTTP2 что тоже ускорит работу... архитектурный паттерн не важны технологии, не мне вам опьянять . важен подход. Например как гексагональная архитектура, без разницы на чем она одна, так и тут.
Так как большинство манипуляций происходит фронт разработчиками которые пишут на js то и в основе аббревиатуры ( надеюсь вы читали) заложен этот смысл. Рекомендую почитать про SSG ( ссылку я уже довал)
Access ( у вас был на локальной машине) вы могли попросить совместно что-то править? вы могли на нем реализовать REST. Вангую что нет. Вот вам и ответ. Headless CMS - это новый уровень классической CMS которые реализуют паттерн микросервестной архитектуры ( надеюсь вам не надо рассказывать что это такое) По этому Access - рядом не стоит .
что касается github - вы упускаете маленький нюанс, и это как в анекдоте про нюансы ( надеюсь знаете). Нам надо не только сгенерировать страницы но и выгрузить на хостинг(CDN) для понимания рекомендую ознакомиться как работает netlife
Где мои слова расходиться с тем что написана на оф сайте?
Сейчас немного подругому
Так все-таки, то, что я описал — Jamstack или нет? и почему?
CDN — это всего лишь способ быстрого доставки нужной (статической информации) до клиента.
… и что?
Так как большинство манипуляций происходит фронт разработчиками которые пишут на js то и в основе аббревиатуры ( надеюсь вы читали) заложен этот смысл.
Я вот не уверен, что в основе аббревиатуры заложен этот смысл.
Access ( у вас был на локальной машине) вы могли попросить совместно что-то править?
Можно было поднять SQL Server и заменить БД, в локальной сети работало. Еще через несколько лет мы сделали нормальную админку на ASP, но тоже с оффлайн-публикацией.
вы могли на нем реализовать REST.
А зачем?
Headless CMS — это новый уровень классической CMS которые реализуют паттерн микросервестной архитектуры
А откуда вы это взяли, простите? В википедии сказано "most… employ a version of", но это не обязательный компонент.
Ну и да, а вы уверены, что Headless CMS — это обязательный компонент Jamstack? В расшифровке "JS/API/Markup" headless cms нет.
что касается github — вы упускаете маленький нюанс
… какой?
Нам надо не только сгенерировать страницы но и выгрузить на хостинг(CDN)
Так для этого гитхаб не нужен.
Где мои слова расходиться с тем что написана на оф сайте?
Там, где вы говорите, что "Апи нужно для того что бы сгенерировать статичную страницу."
Вклинюсь в дискуссию.
Если откинуть детали, то JAMStack-сайт не отличается от простого статического сайта, по типу тех, что делали в 90е-00е. Идея JAMStack в том и состоит, чтобы заранее сгенерировать кучу .html файликов, положить их на любой хостинг и оттуда раздавать со всеми вытекающими плюсами и минусами.
JAMStack говорит: "давайте возьмём идею готовых статических страниц из прошлого, доработаем её, добавим привычные и хорошо знакомые фронтенд-разработчикам инструменты, сложные детали и логику спрячем за SaaS решениями (если нужны, можно и без них), создадим вокруг этого экосистему и дадим фронтенд-разработчикам".
Ключевая особенность в том, что сайт создаётся силами фронтенд-разработчика на привычном для него инструменте, будь то обычный html или react, или ещё что-то. Собирается это тоже любым привычным инструментом, будть то grunt, gulp, webpack, vite, либо же специализированными генераторами, вроде jekyll, hygo, eleventy. Данные для страниц тоже берутся привычным способом - запрос к API с получением json через fetch, XHR или какой-нибудь GraphQL. Деплоится это тоже привычным способом - git push, а дальше путем нажатий пары кнопок, авторизации через гитхаб и некоторой магии, это все оказывается, на амазоновском облаке, на CDNке или где-то ещё (смотря что выбрать).
То есть фронтенд-разработчик может сам сделать шаблоны, настроить получение и вывод данных, логику отображения. И все без привлечения бекенд-разработчика и вообще без разработки бекенда. Не надо ковыряться в php, лазить на хостинги, настраивать htaccess-ы, смотреть таблички в базе, переживать что админку взломают. Взял, написал на своих технологиях, сбилдил, залил - статический сайт готов. А все остальное дают сервисы.
Спасибо, вот это объяснение намного понятнее, чем статья.
Хотя, впрочем, один вопрос остается: разве jekyll или hygo — это то, чем фронтенд-разработчик пользуется в нормальной привычной жизни? Jekyll вон вроде бы вообще на Ruby, и темплейтинг там свой собственный.
Хотя, впрочем, один вопрос остается: разве
jekyllилиhygo— это то, чем фронтенд-разработчик пользуется в нормальной привычной жизни?
Скажем так, конкретно эти и некоторые другие генераторы не то, чем активно пользуются фронты. Но спасоб написания привычный - html-шаблоны с markdown, шаблонизатором (в случае Jekyll это liquid) и JavaScript. Говоря о шаблонизаторах, это привычная для фронтов штука и в целом они сильно друг на друга похожи (тот же liquid, nunjucks и twig почти близнецы).
Однако если jekyll штука специфическая, то можно взять Gatsby и писать на React со всеми сопутствующими вещами. И это уже ближе к тому, чем фронты обычно занимаются.
Jekyll вон вроде бы вообще на Ruby, и темплейтинг там свой собственный.
Даже если у вас будет какая-то своя программа, скажем, на Java, которая даёт возможность создавать шаблоны без написания Java-кода при помощи фронтенда, при этом умеет из этих шаблонов собрать статические html-ки, правильно настраивать роутинг, обрабатывать ресурсы и давать вспомогательный инструментарий для разработчика, то по сути это тоже будет статический генератор и такой сайт попадёт под понятие JAMStack.
Хотя более каноничным, что-ли, считается подход, когда генератор написан на js, сборка на js, шаблоны на html+js или шаблонизаторе. Тогда фронты максимально абстрагируются от других языков, их экосистем, пакетных менеджеров и необходимости что-то разворачивать.
Скажем так, конкретно эти и некоторые другие генераторы не то, чем активно пользуются фронты.
Вот и мне так казалось. Но при этом я больше одного раза слышал упоминание jekyll в контексте Jamstack.
Даже если у вас будет какая-то своя программа, скажем, на Java, которая даёт возможность создавать шаблоны без написания Java-кода при помощи фронтенда
Забавно, конечно. Использование JS — ок. Использование встроенных DSL, как в Jekyll — ок. А использование других языков программирования — не ок?
Хотя более каноничным, что-ли, считается подход, когда генератор написан на js, сборка на js, шаблоны на html+js или шаблонизаторе.
Ну у нас вот шаблоны были на XSLT во время оно. Куда уж абстрактнее...
Вот и мне так казалось. Но при этом я больше одного раза слышал упоминание jekyll в контексте Jamstack.
Да, потому что Jekyll это старожил среди генераторов и одно из самых популярных решений. Также часто можно услышать про gatsby в контексте Jamstack. Эти генераторы есть чуть ли не на любом языке и под любой шаблонизатор, полный список тут.
Забавно, конечно. Использование JS — ок. Использование встроенных DSL, как в Jekyll — ок. А использование других языков программирования — не ок?
Суть в том, что это преподносится как фронтенд-решение, поэтому другие языки не ок. При том под капотом генератор может быть написан на чём угодно. Суть же первой буквы в JavaScript и последней в Markup. Под Markup понимается как обычный HTML, так и другие форматы разметки, например markdown, шаблонизаторы, и да, XSLT тоже можно тоже к этому отнести
то есть опционально, и в очень урезанном виде по сравнению с классической схемой.
Не понимаю смысла JAMStack, хоть убей. Особенно на западе, откуда это пришло. Оплата сервера, который будет способен отдавать статику и делать простейшую логику при необходимости стоит как 1 час работы фронтендера, который сможет грамотно весь этот набор кривых сервисов интегрировать.
В сухом остатке видится как демпинговая технология когда белые люди нанимают людей из стран третьего мира, экономя на всем за счет времени программиста, которое толком не оплачивается. Потому что, напомню, чтобы сделать сайт на джэмстеке хорошо, нужен хороший программист, который возьмет дорого. Ну или можно нанять студентов/индусов и бесконечно полоскать им мозги.
И главное те же headless cms начнут требовать деньги, когда вы добавите слишком много товаров или захотите кастомную логику.
Основное преимущество - высокая скорость отдачи контента, а как следствие - хорошие показатели Web Vitals. Достигается за счёт того, что на сервере лежат готовые html-файлы, которые сразу отдаются пользователю по запросу. Нет расходов на поход в базу, обработку данных, построение view, обработку роутов и тд. Ну и размещение на CDN тоже часто позволяет скорость отдачи увеличить.
Другое преимущество - безопасность. Файлы лежат в виде обычных html на простейшем хостинге статики, там нечего взламывать, чем в случае с CMS по типу WordPress. А если используется Headless CMS, то безопасность уже гарантируется поставщиком этой CMS.
Для простых небольших проектов это ещё и дёшево. Хранить статику сейчас очень дёшево, а иногда и вообще бесплатно. Плюс есть куча сервисов с бесплатными тарифами, тот же Netlify даёт в бесплатном пакете все необходимое для блога - ci, интеграцию с гит-хостингами, безлимит по количеству сайтов, имеет интеграцию со многими популярными генераторами. Поэтому можно собрать сайт и платить только за домен.
Ну и ещё к преимуществам можно отнести то, что это frontend-based решение и оно позволяет фронтам не разбираться с бэкендом, абстрагируясь от этого.
JAMStack хорошо подходит для блогов, новостных сайтов, документации, wiki-ресурсов, для визиток и корпоративных сайтов. Хотя создают и eCommerce на нем.
Все эти преимущества достигаются и традиционными генераторами типа Jekyll. Наверняка даже есть те что с веб-мордой для редактирования контента. Насколько мне известно, для высоких показателей скорости используется пререндеринг, а гидрация уже происходит потом, и не важно будет она из headless cms или из своего API(на базе той же готовой strapi). Но для такого нужны программисты знающие что-то за пределами фронтенда, хотя бы минимально. И поэтому единственный плюс для заказчика - возможность нанять студента за миску риса, чтобы здесь и сейчас что-то сделать. И несмотря на все дифирамбы по скорости, быстрый сайт не получится у такого человека. Там будет просто лепнина из скриптов и компонентов, лишь бы все примерно выглядело как хочет закачик. Оптимизировать это будет стоить дороже чем сделать.
Так jekyll и является одним из вариантов создания сайта на JAMStack
Формально вы правы. Но в 99% случаев коммерческий JAMStack это кривые поделия на Next/Nuxtjs и ко, привязанные к условной netlify. Это во что выродился термин Jamstack. Если вы в среде фронтендеров всерьез будете рассуждать о коммерческих сайтов на Jekyll, то вас скорее всего не поймут. Копир стал ксероксом.
Вы забываете про производительность сервера и DDoS protection. При SSR вы получите совершенно другие (на порядки) показатели стоимости (CPU use perspective).
Отдавать HTML одно ядро может (грубо) 500K RPM.
А эффективность кэширования статических страниц позволяет на порядки! увеличить это значение. Для нагруженных сайтов получаем огромную финансовую разницу (не говоря о latency).
А SSR - уже в десятки раз медленнее.
С защитой то же самое.
возможность запуска и отображения данных в оффлайн-режиме с моментальной загрузкой;
каких данных?.. режим же оффлайн)) старых.. неактуальных данных - это да.
Спасибо@Evil_Evis- забрал статью в закладки. Я бы добавил ещё пару моментов к статье и бурной дискуссии.
Во-первых, количество готовых тем для сайта, например, таких http://jekyllthemes.org/. Тут джекилл чемпион, сотни бесплатных и ещё больше недорогих тем. На гитхаб пейджис 12 тем джекила с самого начала. Есть готовые темы и для других SSG .
Во-вторых, jamstack подход сильно изменил работу фронтэндеров. Идея разделить дизайн сайта и его содержимое привлекла тысячи программистов, создавших и постоянно пополняющих подобные ресурсы. Да и отношение заказчиков к созданию сайта становится другим. Использовал гитхаб пейджис в курсе облачных сервисов для магистрантов - https://ophilon.github.io/blog/lab06.html, на прощание порекомендовал:
Конечно, с ростом популярности ваш сайт превысит лимиты бесплатных сервисов. Но важно то, что к тому времени вы будете ориентироваться в дизайне сайтов, научитесь анализировать его эффективность, работать с пользователями, и многое другое. Немаловажно, вы будете знать, каких специалистов с какими знаниями привлекать для дальнейшего развития
Публикации
JAMstack — зачем, почему и за что