PHP vs JAM (Gatsby.js or Next.js) стэк, или что не так с SSG сайтами?

На днях мой заказчик спросил меня не хочу ли я сменить стэк технологий на его новом eCommerce проекте с PHP (не буду уточнять CMS и frameworks которые я использую) на NextJS с Vercel или Gatsby с Netlify, так как он успешно использует это на других своих проектах.
Мне конечно удалось отговорить его от смены технологий, но мне показались мои аргументы слегка надуманными так как я не имею опыта в создании SSG сайтов, а в интернете мне удалось нагуглить только много хорошего...

Давайте обсудим, действительно ли статические сайты так хороши как о них пишут и почему у Gatsby.js и Next.js по 50k звездочек на github

Пожалуйста, те кто имеют опыт с этими технологиями помогите мне ответить на следующие вопросы:

1) Действительно ли Gatsby.js и Next.js, подходит только для создания сайтов со статическим контентом (блогов и документаций)?
2) С какими трудностями можно столкнуться при создании eCommerce сайта на Gatsby.js или Next.js?
3) С какими трудностями можно столкнуться при создании большого сайта (допустим блога с около миллиона страниц) с использованием SSG?
4) Действительно ли JAM-стэк конкурент классической разработке сайтов на Laravel, Magento или WordPress?
  • Вопрос задан
  • 587 просмотров
Пригласить эксперта
Ответы на вопрос 2
index0h
@index0h
PHP, Golang. https://github.com/index0h
1. Gatsby использует GraphQL для динамики, Next - для статических сайтов.
2. Для Gatsby вам прийдется побороть GraphQL (если вы не уровня Facebook - это плохая идея). Для Next - просто отдельно реализовать eCommerce проект.
3. Перекомпиляция и обновление данных.
4. Если фреймворк помогает в решении задач проекта - да. Но часто это обычный хайп.
Ответ написан
Комментировать
profesor08
@profesor08 Куратор тега PHP
Если на сайте не динамического контента, который может меняться самостоятельно, то вполне себе можно просто сгенерировать все странички и перегенерировать их при необходимости. Но это подойдет разве что для лендингов. Если взять что-то сложнее, например блог, то очень быстро надоест после каждого добавления статьи генерировать все страницы. Терпимо, если раз в месяц, если чаще то уже не удобно. Если много страниц, то это дело будет занимать все больше и больше времени. Если их миллион, то все это дело может работать медленнее обычной cms, из-за IO операций.

1. нет, можно делать сайты любой сложности.
2. не надо будет подбивать html шаблоны под движок, между клиентом и сервером гоняются только данные, а не разметка. Тут разве что может возникнуть сложность из-за психологического барьера и нежелания что-то менять.
3. чуть выше написал, время, IO, лишний гемор и стресс.
4. это очень субъективно - кому что нравится.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы