Статья действительно больше про энтузиазм, чем про конкретику. Почему Strapi считается Headless? Потому что его основная задача - управлять контентом и предоставлять его через API для любого фронтенда, а встроенная админка - просто удобный интерфейс для управления контентом, но она не диктует, как и где этот контент будет отображаться. Чем все же хороша связка? Резюмируя информацию из статьи - связка Strapi + Next.js хороша благодаря гибкому API (REST/GraphQL) и универсальному рендерингу Next.js (SSG, SSR, ISR), обеспечивая классную высокую производительность и SEO.
Нужны примеры? Давайте рассмотрим:
Strapi+Next.js VS Wordpress - WordPress рендерит страницы на сервере через PHP, что медленнее, чем SSG у Next.js. Для мультиканальных проектов (веб + мобильное приложение) нужно дополнительно настраивать API (например, WP REST API). А также монолитная архитектура, ограниченная гибкость фронтенда, производительность хуже из-за генерации страниц из-за того же PHP.
Strapi+Next.js VS Contentful (тоже headless) - Прежде всего перед Вами зависимость от подписки, ограничения на кастомизацию, а стоимость растет с масштабом. Contentful проще для старта, но если нужно сложное API с кастомной логикой (например, агрегация данных из нескольких источников), Strapi выигрывает за счет open-source и возможности доработки.
И наконец, не оставим без внимания кейс связки Strapi с другим фреймфорком на React. Strapi+Next.js VS Strapi+Gatsby - из рендеринга только SSG, ограниченная поддержка динамического контента (SSR/ISR сложнее). Gatsby подходит для блогов или документации, но для динамических приложений. Next.js более гибок за универсальности счет вышеперечисленных способов рендеринга.
В окончание добавлю, что в каждом подходе можно найти как плюсы так и минусы, выбор нужно делать с умом основываясь на результате, который хотите достичь)
В целом всё чуть наоборот. В статье формально описан реальный кейс, который нам удалось разработать У заказчика в 1С CRM может быть описана вся бизнес логика, с которой работают его менеджеры, но без "витрины". Можно обойтись "малой кровью" и просто подвязать фронт на 1C, дописав внутри логику взаимодействия по REST. Можно просто "вытащить" наружу 1С с добавленными формами и документами, но это уже совсем. В статье же описан подход, который минимизирует имеющиеся риски взаимодействия с 1С CRM. С данным подходом можно сделать небольшие доработки на стороне Мастер системы, сделать безопасную и быструю B2B витрину или Личный кабинет.
Статья действительно больше про энтузиазм, чем про конкретику. Почему Strapi считается Headless? Потому что его основная задача - управлять контентом и предоставлять его через API для любого фронтенда, а встроенная админка - просто удобный интерфейс для управления контентом, но она не диктует, как и где этот контент будет отображаться.
Чем все же хороша связка? Резюмируя информацию из статьи - связка Strapi + Next.js хороша благодаря гибкому API (REST/GraphQL) и универсальному рендерингу Next.js (SSG, SSR, ISR), обеспечивая классную высокую производительность и SEO.
Нужны примеры? Давайте рассмотрим:
Strapi+Next.js VS Wordpress - WordPress рендерит страницы на сервере через PHP, что медленнее, чем SSG у Next.js. Для мультиканальных проектов (веб + мобильное приложение) нужно дополнительно настраивать API (например, WP REST API).
А также монолитная архитектура, ограниченная гибкость фронтенда, производительность хуже из-за генерации страниц из-за того же PHP.
Strapi+Next.js VS Contentful (тоже headless) - Прежде всего перед Вами зависимость от подписки, ограничения на кастомизацию, а стоимость растет с масштабом. Contentful проще для старта, но если нужно сложное API с кастомной логикой (например, агрегация данных из нескольких источников), Strapi выигрывает за счет open-source и возможности доработки.
И наконец, не оставим без внимания кейс связки Strapi с другим фреймфорком на React.
Strapi+Next.js VS Strapi+Gatsby - из рендеринга только SSG, ограниченная поддержка динамического контента (SSR/ISR сложнее). Gatsby подходит для блогов или документации, но для динамических приложений. Next.js более гибок за универсальности счет вышеперечисленных способов рендеринга.
В окончание добавлю, что в каждом подходе можно найти как плюсы так и минусы, выбор нужно делать с умом основываясь на результате, который хотите достичь)
Спасибо большое за замечание! Исправил
В целом всё чуть наоборот. В статье формально описан реальный кейс, который нам удалось разработать
У заказчика в 1С CRM может быть описана вся бизнес логика, с которой работают его менеджеры, но без "витрины". Можно обойтись "малой кровью" и просто подвязать фронт на 1C, дописав внутри логику взаимодействия по REST. Можно просто "вытащить" наружу 1С с добавленными формами и документами, но это уже совсем.
В статье же описан подход, который минимизирует имеющиеся риски взаимодействия с 1С CRM. С данным подходом можно сделать небольшие доработки на стороне Мастер системы, сделать безопасную и быструю B2B витрину или Личный кабинет.