Headless Ghost: кастомный фронтенд с Content API

Headless-архитектура с Ghost: от API до готового фронтенда

Handlebars-темы Ghost дают ограниченную гибкость: любой нестандартный UI требует переписывания шаблонов, а производительность страдает из-за серверного рендеринга без кэширования. Ghost Content API — это публичный REST-интерфейс только для чтения, который позволяет отделить бэкенд от фронтенда. Мы используем такой подход в каждом headless-проекте: база данных и админка остаются на Ghost, а UI строится на Next.js, Astro или Vue. Результат — полный контроль над дизайном и Core Web Vitals на уровне 90+.

Что такое Ghost Content API и как он работает?

Ghost Content API v5 предоставляет доступ к контенту через стандартные HTTP-запросы. Он возвращает JSON с постами, страницами, тегами и авторами. В отличие от Handlebars, вы получаете сырые данные и строите интерфейс сами. API оптимизирован для чтения: среднее время ответа — менее 30 мс при 10 000 постах. Аутентификация выполняется через публичный API-ключ, который можно безопасно использовать на фронтенде.

Как работает аутентификация в Ghost Content API?

Content API Key создаётся в Ghost Admin: Settings → Integrations → Add custom integration. Ключ передаётся как query-параметр или заголовок. Он публичный (read-only), поэтому его можно использовать на фронтенде без дополнительной авторизации.

// lib/ghost.ts
import GhostContentAPI from '@tryghost/content-api';

export const ghostClient = new GhostContentAPI({
  url: process.env.GHOST_URL!, // https://myblog.com
  key: process.env.GHOST_CONTENT_API_KEY!,
  version: 'v5.0',
});

Основные методы Ghost Content API

SDK предоставляет методы browse для списков и read для единичных записей. Поддерживает пагинацию, фильтры, выбор полей и включение связанных данных (авторы, теги). Для типичного блога достаточно posts.browse и posts.read. Обратите внимание на параметр formats: html или plaintext.

// Список постов с пагинацией
const posts = await ghostClient.posts.browse({
  limit: 10,
  page: 2,
  include: ['tags', 'authors'],
  filter: 'tag:javascript+featured:true',
  order: 'published_at DESC',
  fields: 'id,title,slug,excerpt,feature_image,published_at',
});
// posts.meta.pagination: { page, limit, pages, total, next, prev }

// Один пост по slug
const post = await ghostClient.posts.read(
  { slug: 'my-post-slug' },
  { include: ['tags', 'authors'], formats: ['html', 'plaintext'] }
);

// Страницы, теги, авторы, настройки — аналогично

Next.js App Router интеграция

В App Router данные получаем в Server Components. ISR с revalidate позволяет обновлять кеш без пересборки. Для страниц-списков удобно использовать generateStaticParams с limit: 'all'. Такой подход даёт статическую генерацию (SSG) с возможностью инкрементального обновления.

// app/blog/page.tsx
import { ghostClient } from '@/lib/ghost';

export const revalidate = 3600;

export default async function BlogPage() {
  const posts = await ghostClient.posts.browse({
    limit: 12,
    include: ['tags', 'authors'],
  });

  return <PostGrid posts={posts} />;
}

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await ghostClient.posts.browse({ limit: 'all', fields: 'slug' });
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({ params }) {
  const post = await ghostClient.posts.read(
    { slug: params.slug },
    { include: ['tags', 'authors'] }
  );
  return <PostDetail post={post} />;
}

Рендер Ghost HTML с помощью DOMPurify

Ghost возвращает готовый HTML в поле html. Для безопасного рендера используйте санитизацию DOMPurify и отдельные стили для карточек Ghost. Этот подход подходит для React, Vue и других фреймворков.

// components/GhostContent.tsx
import DOMPurify from 'isomorphic-dompurify';

export function GhostContent({ html }: { html: string }) {
  const clean = DOMPurify.sanitize(html, {
    ADD_TAGS: ['iframe'],
    ADD_ATTR: ['allowfullscreen', 'frameborder'],
  });

  return (
    <div
      className="ghost-content prose prose-lg max-w-none"
      dangerouslySetInnerHTML={{ __html: clean }}
    />
  );
}

CSS для Ghost card-элементов подключается отдельно: @/styles/ghost-cards.css (содержит стили для kg-bookmark, kg-gallery, kg-video и т.д.).

Как решить проблему Members API в headless-режиме?

Members-функции (paywall, подписки) в headless-режиме сложнее. Ghost предоставляет Portal — iframe-виджет для входа. Его можно встроить в любой фронтенд.

<script src="https://myblog.com/public/member-attribution.min.js" async></script>
<button onclick="window.location.href='https://myblog.com/#/portal/signup'">Подписаться</button>

Полноценная интеграция с Members требует проксирования сессий через Ghost API — это оправдано только для коммерческих проектов с подписками.

Когда стоит выбрать headless-архитектуру?

Если ваш блог требует уникального UI, кастомных анимаций или сложной логики на клиенте, headless — единственный путь. Нативные темы Ghost быстрее в разработке, но проигрывают в гибкости и производительности. Сравним:

Ghost Content API в паре с Next.js даёт Core Web Vitals на уровне 90+. Ghost Content API быстрее GraphQL-решений на 30% в простых запросах (согласно нашим тестам с Apollo Client). Headless-архитектура снижает затраты на поддержку на 30-50% за счёт переиспользования компонентов. Свяжитесь с нами для аудита вашего блога — мы поможем оценить потенциальную экономию.

Что входит в нашу работу?

1. Аудит текущей архитектуры и требований.
2. Настройка Content API и создание необходимых интеграций.
3. Разработка кастомного фронтенда на Next.js, Astro или Vue.
4. Интеграция Members Portal (если нужны подписки).
5. Тестирование Cross-Browser и производительности.
6. Передача документации по API и структуре данных.
7. Гарантийная поддержка 1 месяц после запуска.

Ориентировочные сроки

Получите консультацию: расскажите о задаче, и мы предложим прозрачный план с фиксированным сроком. Инвестиции в headless-архитектуру окупаются за 6–12 месяцев за счёт роста конверсии и улучшения SEO.

Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal

Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу. Я сталкивался с этим десятки раз: сайт на WordPress с ACF разрастается до 47 плагинов, админка тормозит, а каждый редизайн превращается в переписывание шаблонов.

Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта. За более чем 7 лет мы провели более 50 внедрений — расскажу, как не наступить на типичные грабли.

Почему headless CMS выгоднее монолита?

Монолитная CMS (WordPress, Joomla, Drupal в классическом режиме) смешивает бэкенд и фронтенд. Любое изменение вёрстки — это изменение шаблонов, часто с риском поломать админку. Headless даёт свободу: фронтенд на React, Vue или Svelte, а контент живёт отдельно. Результат — скорость загрузки (LCP часто падает с 4-6 с до 1-1,5 с), безопасность (нет публичного доступа к админ-панели), масштабирование (контент отдаётся через CDN без нагрузки на сервер). Плюс возможность переиспользовать контент в мобильных приложениях, киосках, email-рассылках через единый API.

Какую headless CMS выбрать под проект?

Нет универсального инструмента. Выбор зависит от команды, сложности контента и инфраструктуры. Разберём ключевые варианты.

Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Разворачивается за час — в 3 раза быстрее Drupal. Слабое место — версии v4 и v5 несовместимы между собой, миграция болезненная. Наш опыт показывает: для стартапов и средних проектов Strapi — оптимальный баланс гибкости и скорости.

Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API. Экономия времени на этапе интеграции — до 30%.

Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами. Гарантирует скорость даже при 500+ одновременных редакторах — проверено на проектах с ежеминутным обновлением ленты новостей.

Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.

Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость, гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, для сложных государственных или корпоративных порталов альтернатив мало. Мы используем его только когда требуется строгая иерархия ролей и аудит доступа.

Последствия неправильного моделирования контента

Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная проблема: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone. Мы всегда закладываем на этапе проектирования 2-3 итерации с заказчиком, чтобы схема покрывала 90% будущих кейсов. На одном проекте это сэкономило 80 часов переработок — бюджет на моделирование окупился втрое.

Как мы строим проекты на headless CMS

Фронтенд под headless CMS практически всегда идёт на Next.js (App Router) или Nuxt. Для Contentful и Sanity — ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.

Кейс: редизайн корпоративного сайта производственной компании. Предыдущий сайт — WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3,8 с, редакторы жаловались на медленный админ.
Перешли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентная модель: Page с Dynamic Zone (секции Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.

TTFB с 3,8 с упал до 180 мс (статика с CDN) — разница в 21 раз. Редакторы получили чистый интерфейс без 47 плагинов. Стоимость проекта — в диапазоне 300 000 – 500 000 рублей, экономия на хостинге после миграции — около 15 000 рублей в месяц.

Для понимания headless CMS и TTFB — рекомендую базовые статьи.

Процесс внедрения разбит на этапы:

1. Аудит контентных потребностей — собираем все типы контента, связи, требования к локализации, интеграции.
2. Проектирование схемы данных — создаём модели, поля, валидацию, роли доступа. Документируем в Swagger/OpenAPI.
3. Настройка CMS и API — разворачиваем выбранную CMS, настраиваем REST/GraphQL endpoints, плагины, webhooks.
4. Разработка фронтенда — подключаем Next.js/Nuxt, настраиваем ISR/SSR, компоненты секций, роутинг.
5. Миграция контента (если есть legacy) — автоматическая загрузка через API или скрипты.
6. Тестирование — проверка API endpoints, регрессия, нагрузочное тестирование, Core Web Vitals.
7. Деплой — настройка CDN, SSL, CI/CD, мониторинг.

Сколько времени занимает внедрение?

Стандартный путь включает все этапы. Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой. Наши средние сроки:

Стоимость рассчитывается индивидуально после брифа. Бюджет типового внедрения — от 150 000 до 500 000 рублей в зависимости от сложности. Экономия на хостинге за счёт статической генерации — до 40% в месяц.

Что входит в работу

• Документация схемы данных и API (Swagger/OpenAPI)
• Настроенная админ-панель с правами доступа
• Обучение редакторов (2-часовая сессия)
• Тестовый стенд на время разработки
• Гарантия 1 месяц на баги после запуска
• Поддержка после релиза (включая хотфиксы 24/7)

Headless CMS разработка — это не просто замена инструмента, а смена парадигмы работы с контентом. Мы помогаем сделать этот переход без простоев и потери данных. Получите консультацию и предварительную оценку — оставьте заявку на сайте. Закажите внедрение headless CMS с гарантией результата.