Gatsby связывает сайты на React со структурированным контентом и гибким рендерингом
Что представляет собой Gatsby?
Gatsby — это React-фреймворк для создания сайтов из компонентов и структурированного контента. Он может собирать данные из файлов, систем управления контентом, API и других сервисов, организовывать эти данные с помощью слоя GraphQL и использовать их для создания страниц со статическим, отложенным, серверным или клиентским рендерингом.
Gatsby — это фреймворк. gatsbyjs.com — его официальный сайт и центр документации. Это различие важно, поскольку предметом данного руководства являются архитектура, пакеты и репозиторий фреймворка, а домен служит местом публикации документации проекта.
Проект Gatsby обычно объединяет несколько задач в одном рабочем процессе:
- Компоненты React определяют интерфейс и многократно используемые элементы страниц.
- Плагины источников импортируют контент и данные из локальных или удалённых систем.
- Gatsby нормализует полученные записи в узлы своего слоя данных.
- Запросы GraphQL выбирают поля, необходимые страницам и компонентам.
- API страниц и шаблоны превращают данные в маршруты.
- Настройки рендеринга определяют, когда создаётся каждая страница.
Как Gatsby связан с React
React предоставляет Gatsby модель компонентов. Разработчики создают макеты, навигацию, шаблоны и интерактивные функции из компонентов React, а Gatsby предоставляет окружающий их фреймворк для маршрутизации, получения данных, создания страниц, обработки ресурсов и формирования конечного результата для рабочей среды.
Таким образом, Gatsby не является ни заменой React, ни просто библиотекой компонентов. Это структурированный фреймворк для сайтов, построенный вокруг React. Команды могут применять знакомые JSX, композицию компонентов, свойства, состояние и взаимодействие на стороне браузера, используя при этом специфичные для Gatsby API для работы с данными и рендерингом.
Что Gatsby добавляет к React
| Задача | Что предоставляет React | Что добавляет Gatsby |
|---|---|---|
| Интерфейс | Компоненты и состояние | Соглашения для страниц, макеты и интеграцию со сборкой |
| Данные | Выбор способов получения данных на уровне приложения | Нормализованный слой данных и рабочий процесс запросов GraphQL |
| Маршруты | Строительные блоки приложения | Страницы на основе файлов, программное создание страниц и маршруты только для клиента |
| Результат | Интерфейсы, отрисовываемые в браузере | Статический, отложенный и выполняемый во время запроса рендеринг страниц |
| Интеграции | Общую экосистему JavaScript | Плагины, темы, стартовые проекты и API жизненного цикла фреймворка Gatsby |
Такая структура может подойти команде React, создающей публичный сайт с большим объёмом контента. Она может быть избыточной, если небольшой проект почти не нуждается в интеграции контента или если его требования в основном соответствуют приложению с клиентским рендерингом.
Слой данных и GraphQL
Слой данных Gatsby предназначен для предоставления различным источникам контента общего интерфейса запросов. Плагины источников получают записи и создают узлы Gatsby. Затем Gatsby делает эти узлы доступными через схему GraphQL, к которой могут обращаться страницы и компоненты.
Сайт может объединять файлы Markdown, изображения, безголовую систему управления контентом и выбранные данные сервисов. Вместо того чтобы каждая страница разбиралась в исходном формате ответа каждого источника, Gatsby может предоставить соответствующие записи через общий граф.
Типичный путь контента выглядит так:
- Файл, сервис или контентная платформа хранит исходный материал.
- Плагин источника импортирует этот материал в процессе получения данных Gatsby.
- Gatsby представляет импортированные записи в виде узлов и строит схему.
- Запросы GraphQL запрашивают поля, необходимые странице или компоненту.
- Шаблон использует результат запроса для создания страницы.
- Gatsby отрисовывает страницу в соответствии с выбранным режимом рендеринга.
GraphQL занимает центральное место в рабочем процессе Gatsby с данными из источников, но не заменяет все обычные значения React. Свойства компонентов, локальное состояние, события браузера и клиентские запросы по-прежнему могут существовать вне графа, формируемого во время сборки. Важно понять, упрощает ли общая схема Gatsby сбор контента, из которого должны составляться страницы.
Слой данных также создаёт дополнительную работу. Командам необходимо понимать поведение источников, связи между узлами, изменения схемы и зависимости запросов. Граф, объединяющий несколько систем, может быть полезен, но стоимость его сборки и затраты на сопровождение следует проверять на репрезентативном контенте, а не определять по стартовому сайту.
Плагины источников и более широкая модель расширения
Плагины источников подключают Gatsby к данным. Они могут читать локальные файлы или интегрировать контентные системы и сервисы, а затем создавать узлы, участвующие в слое GraphQL. Этим они отличаются от плагинов, добавляющих обработку, аналитику, стилизацию, поддержку изображений или другое поведение жизненного цикла.
Gatsby упаковывает многократно используемые наработки в три связанные формы:
- Плагины добавляют источник, преобразование, интеграцию или возможность фреймворка.
- Темы объединяют многократно используемые конфигурацию и функциональность Gatsby, которые сайты могут расширять.
- Стартовые проекты предоставляют исходный проект, который разработчики копируют и адаптируют.
Стартовый проект может сократить время настройки, но его зависимости и соглашения становятся ответственностью принявшей его команды. Тема может обеспечивать единообразие функциональности на разных сайтах, однако командам следует понимать, что именно она контролирует. Плагин может избавить от написания собственного интеграционного кода, хотя его совместимость и сопровождение необходимо оценивать отдельно.
Наличие обширной категории плагинов не доказывает, что конкретный пакет поддерживает версию Gatsby, источник данных или модель развёртывания команды. Практическая оценка должна определить точные необходимые пакеты, изучить их документацию и активность репозиториев, а также протестировать их в предлагаемой архитектуре.
Варианты рендеринга в Gatsby
Изначально Gatsby прочно ассоциировался с генерацией статических сайтов, но теперь его документация определяет несколько вариантов рендеринга. Их можно выбирать отдельно для каждой страницы, чтобы публичная статья, большой архив, зависящий от запроса маршрут и раздел приложения могли использовать разные модели формирования результата.
| Вариант рендеринга | Когда создаётся страница | Подходящий вопрос |
|---|---|---|
| Генерация статического сайта (SSG) | Во время сборки | Доступен ли необходимый странице контент до развёртывания? |
| Отложенная статическая генерация (DSG) | При первом запросе отложенной страницы | Можно ли исключить эту страницу из первоначальной сборки и поддерживает ли хост Gatsby DSG? |
| Серверный рендеринг (SSR) | Во время запроса с использованием getServerData |
Требуются ли ответу данные или контекст, доступные во время запроса? |
| Клиентский маршрут | В браузере для пути приложения | Задуман ли этот раздел как приложение и что доступно до завершения выполнения JavaScript? |
Статические и отложенные страницы
SSG создаёт HTML и связанные ресурсы во время сборки. Это естественный вариант для контента, исходные данные которого известны заранее. Созданные файлы может быть просто распространять, однако большое количество страниц, дорогостоящие запросы, многочисленные источники контента или ресурсоёмкая обработка изображений могут повысить требования к сборке.
DSG откладывает создание выбранных страниц до их первого запроса. Это может уменьшить количество страниц, создаваемых при первоначальной сборке, особенно если на сайте есть длинный хвост редко запрашиваемого контента. Для этого также требуется среда развёртывания, реализующая поведение отложенной генерации Gatsby; это не равнозначно загрузке только статических файлов на любой хост.
Рендеринг во время запроса и в браузере
SSR формирует ответ во время запроса через API Gatsby getServerData. Он может обслуживать страницы, результат которых зависит от актуальной на момент запроса информации, но добавляет серверное выполнение, решения по кэшированию, обработку сбоев и инфраструктурные требования, которых нет у полностью статической страницы.
Клиентские маршруты поддерживают разделы приложения, обрабатываемые в браузере. Они могут сосуществовать с генерируемыми публичными страницами, но командам следует изучить состояния загрузки, навигацию, доступность и контент, доступный до запуска клиентского кода. Не следует считать публичную обнаруживаемость гарантированной лишь потому, что маршрут в браузере в итоге отображает нужную информацию.
Ни одно обозначение рендеринга не гарантирует скорость или видимость в поиске. Результаты зависят от дизайна страницы, JavaScript, ресурсов, источников данных, кэширования, хостинга и качества реализации. Gatsby предоставляет командам несколько архитектурных вариантов, но не устраняет необходимость их измерять.
Изображения и производство контента
Изображения часто входят в тот же конвейер контента, что и текст со структурированными записями. Плагины Gatsby могут получать файлы изображений, преобразовывать их и связывать обработанные ресурсы с запросами страниц. Затем компоненты могут отрисовывать выбранные данные изображения как часть шаблона страницы.
Полезный редакционный рабочий процесс разделяет обязанности:
- Редакторы управляют заголовками, основным контентом, метаданными и ссылками на изображения в выбранном источнике.
- Плагины источников импортируют эти записи и связанные с ними ресурсы.
- Слой данных Gatsby связывает узлы контента с необходимыми данными изображений.
- Запросы получают только поля и варианты изображений, необходимые шаблону.
- Компоненты предоставляют подписи, альтернативный текст, размеры и поведение макета.
- Рабочая сборка проверяет, что записи, ресурсы и маршруты корректно разрешаются вместе.
Обработка изображений может повысить единообразие, но она всё равно является частью работы при сборке. Командам следует проверить реальное количество и размер ресурсов, установить, как изменения влияют на повторные сборки, и сохранять содержательный альтернативный текст из редакционного источника. Плагин не может решить, является ли изображение информативным, декоративным или достаточно хорошо описанным.
Где Gatsby может хорошо подойти
Gatsby особенно уместен, когда проект уже использует React и должен собирать контент из нескольких систем. Его граф данных может предоставить согласованный слой между этими источниками и использующими их шаблонами страниц.
К распространённым ситуациям, которые стоит оценить, относятся:
- Сайты документации или редакционные сайты, объединяющие файлы, изображения и контентную платформу.
- Маркетинговые сайты с многократно используемыми компонентами React и структурированными записями страниц.
- Издательские проекты с несколькими источниками, которым полезен единый интерфейс запросов.
- Существующие сайты Gatsby, построенные вокруг API страниц, GraphQL и устоявшихся плагинов.
- Крупные коллекции контента, где отдельные страницы могут подходить для DSG.
- Сайты, объединяющие генерируемые публичные страницы с разделами, отрисовываемыми во время запроса или на стороне клиента.
Gatsby может оказаться менее прямым выбором, если у проекта один простой источник контента, ему не нужен нормализованный граф или требуется архитектура приложения, сосредоточенная преимущественно на операциях во время запроса и на стороне клиента. Это архитектурная оценка, а не вердикт о качестве фреймворка.
Компромиссы сборки и развёртывания
Статическая генерация переносит работу на этап до развёртывания. Gatsby может потребоваться получить исходные данные, построить схему, выполнить запросы, создать страницы, обработать изображения, собрать код в пакеты и записать результат. Продолжительность и требования к ресурсам зависят от реального проекта.
При репрезентативной оценке следует фиксировать:
| Область проверки | Что проверить |
|---|---|
| Масштаб контента | Количество страниц, количество узлов, связи и реалистичные размеры записей |
| Надёжность источников | Аутентификацию, ограничения частоты запросов, сбои и воспроизводимое получение данных |
| Запросы | Стабильность схемы, стоимость запросов и ошибки после изменений контента |
| Изображения | Объём обработки, использование памяти, размер результата и редакционные метаданные |
| Рендеринг | Результат SSG, первые запросы DSG, ответы SSR и загрузку клиентских маршрутов |
| Развёртывание | Поддержку каждого выбранного режима, поведение кэширования и восстановление после сбоев |
Небольшая демонстрация не может показать, как будет вести себя полный каталог. Командам следует тестировать чистые сборки, инкрементальные изменения там, где они поддерживаются, недоступность источников контента и страницы как в типичных, так и в крайних частях набора данных.
DSG может перенести работу с первоначальной сборки, а SSR переносит её на время запросов. Это изменения момента выполнения и операционной ответственности, а не бесплатные улучшения производительности. Выбранный хост должен поддерживать необходимое поведение Gatsby, а команда должна понимать, что происходит при холодном запросе или сбое вышестоящего источника.
Gatsby, Astro и другие альтернативы
Gatsby и Astro могут рассматриваться при оценке фреймворков для сайтов, ориентированных на контент, однако они по-разному организуют проекты. Gatsby делает центральными React, свой слой данных GraphQL, плагины источников и API генерации страниц. Astro следует оценивать на основе его собственной документированной архитектуры, а не по умолчанию считать более быстрым или новым решением.
Gatsby заслуживает более пристального рассмотрения, когда команда хочет использовать React во всём интерфейсе, должна обращаться к нескольким нормализованным источникам контента, зависит от интеграций Gatsby или сопровождает устоявшуюся кодовую базу Gatsby. Другой фреймворк может быть проще, если этот граф и жизненный цикл плагинов добавят структуру, не решая реальной проблемы с контентом.
Для полезного сравнения создайте в каждом кандидате один и тот же репрезентативный фрагмент: один источник контента, одну сложную страницу, список, обработку изображений, навигацию и предполагаемый режим развёртывания. Сравните понятность для разработчиков, поведение сборки, результат в браузере, доступность, требования к хостингу и ответственность за сопровождение. Не объявляйте универсального победителя на основании стандартных шаблонов.
Основатель и официальные ресурсы сообщества
В официальной сессии вопросов и ответов сообщества Gatsby, опубликованной 2 апреля 2020 года, Кайл Мэтьюз был указан как «Основатель @ GatsbyJS». Эта датированная атрибуция описывает его историческую роль в данном источнике; её не следует воспринимать как утверждение о нынешнем руководстве Gatsby.
Документация Gatsby направляет разработчиков к официальным каналам сообщества для разных задач:
- Discord указан как место, где можно обратиться к сообществу за помощью в разработке.
- Обсуждения GitHub служат для обсуждения проекта и функций.
- Документация по участию объясняет способы принять участие в проекте.
- Поддерживаемый репозиторий gatsbyjs/gatsby содержит исходный код фреймворка, пакеты, задачи и историю вкладов.
Эти ресурсы помогают читателям проверять документацию, задавать вопросы по реализации и изучать публичную работу над проектом. Их наличие не следует превращать в неподтверждённые утверждения о времени ответа, долговечности пакетов или будущих планах.
Что командам следует решить перед внедрением Gatsby
Составьте карту контента. Определите каждый источник, связи между записями, частоту обновлений и страницы, использующие каждое поле. Это покажет, решает ли нормализованный слой GraphQL Gatsby значимую задачу координации.
Назначьте режим рендеринга репрезентативным страницам. Подтвердите, какие страницы могут быть статическими, какие можно отложить, каким требуется
getServerData, а какие намеренно являются клиентскими. Убедитесь, что целевая среда развёртывания поддерживает получившееся сочетание.Проведите аудит конкретного набора зависимостей. Проверьте необходимые плагины источников, плагины преобразования, темы, стартовые проекты и инструменты для изображений на совместимость с версией Gatsby проекта. Создайте прототипы сомнительных интеграций, прежде чем делать их архитектурными зависимостями.
Протестируйте нагрузку, приближенную к рабочей. Gatsby предлагает цельный фреймворк для React и контента, но его пригодность определяется соответствием данным, страницам, интеграциям и модели хостинга команды, а не общими обещаниями скорости, позиций в поиске или лёгкого масштабирования.
Успешный ответ не гарантирует безопасность. Измерения отражают одно наблюдение в определённый момент времени.