В этой статье представлен обзор современного создания сайтов с помощью JavaScript-фреймворка Next.js и систем управления контентом (CMS), которые поддерживают спецификацию GraphQL. Это включает, помимо прочего, Contentful, Drupal, eZ Platform и WordPress.

Раздельное управление контентом — термин, популярный уже несколько лет. Это означает, что общедоступный веб-сайт построен с использованием некоторых технологий, которые являются внешними по отношению к основным возможностям CMS. Вместо использования внутренних API-интерфейсов для связи с базой данных в разделенном подходе используется внешний API.

Протоколом де-факто, используемым для связи между интерфейсом и сервером, является HTTP (протокол передачи гипертекста), который является основным протоколом, обеспечивающим работу всемирной паутины (WWW). Он имеет широкую поддержку, и с недавними улучшениями в версии HTTP/2, представленной в 2015 году, его все еще можно считать современным.

В дополнение к HTTP используются дополнительные спецификации для определения связи между клиентом и сервером. В настоящее время наиболее распространенным методом является REST (передача репрезентативного состояния), представляющий собой архитектурный стиль, который фокусируется на использовании глаголов HTTP (GET, POST, PATCH…) для определения связи.

Раздельный интерфейс сайта может быть построен с использованием ряда технологий, но чаще всего используется язык JavaScript. Разделенная реализация JS традиционно создавалась с использованием фреймворка, работающего внутри клиента (браузера). Но с 2009 года и появления Node.js в настоящее время стало обычным делом запускать JavaScript и на сервере.

В этой статье основное внимание уделяется двум технологиям создания несвязанных сайтов; GraphQL и Next.js. Оба этих инструмента набрали достаточно оборотов, чтобы удержаться на рынке, что делает их достойными инвестициями для организаций и отдельных разработчиков.

Введение в GraphQL

GraphQL — это спецификация, определяющая, как клиенты могут получать и изменять контент на удаленном сайте. Это спецификация, не привязанная к какому-либо конкретному языку программирования, системе или даже протоколу связи. Как и REST, сегодня GraphQL в основном используется поверх HTTP. В отличие от подходов RESTful, он использует только метод POST из спецификации HTTP.

Еще одна ключевая часть GraphQL заключается в том, что ответы на контент всегда восстанавливаются в точно такой же форме. Это означает, что если мне нужно только отобразить, скажем, заголовок и изображение элемента контента, я буду запрашивать и получать только эти два поля. В стандартном API RESTful я также получил бы блок контента, что в этом случае было бы пустой тратой полосы пропускания.

Говоря о пропускной способности, запросы GraphQL также могут вкладывать несколько результатов в один HTTP-запрос, устраняя накладные расходы для нескольких циклов ответа-запроса, которые часто требуются при работе с RESTful API.

GraphQL также имеет строгую типизацию для отличного пользовательского интерфейса API благодаря хорошему инструментарию и автоматической документации. Все вышеперечисленное обеспечивает отличную эргономику для разработчиков, и живым доказательством этого является количество таких организаций, как GitHub и Facebook, которые используют эти технологии.

Введение в Next.js

Next.js — это фреймворк для разработки веб-приложений общего назначения. Он написан на JavaScript, но в отличие от Angular или Express — предназначен для работы в браузере и на сервере для начала. Это означает, что вы можете совместно использовать один и тот же код во всем приложении без дополнительных затрат на настройку универсальной маршрутизации, рендеринга на стороне сервера (SSR) или других шаблонных задач.

React.js, очень популярная библиотека представлений JavaScript, используется Next.js для предоставления возможностей рендеринга пользовательского интерфейса как на сервере, так и на клиенте. Это также позволяет фреймворку отображать первое представление на сервере, а затем позволяет браузеру взять на себя управление и начать общение с сервером напрямую, в нашем случае через GraphQL.

Вышеупомянутая возможность была доступна в течение нескольких лет, но Next.js — это первый случай, когда она была построена в виде зрелого, простого в использовании и стабильного пакета, рентабельного для разработчиков. Вместе с GraphQL он открывает мир несвязанного создания сайтов, который обеспечивает прочную основу для сайта, ориентированного на контент, с богатыми функциями электронной коммерции на основе API от Sylius или других современных пакетов электронной коммерции.

Преимущества использования GraphQL и Next.js

Самое большое преимущество использования такой комбинации, как GraphQL и Next.js, может дать разработчикам сайтов возможность использовать новые технологии. Это может не дать никакого технического вознаграждения, но мотивирует разработчиков CMS и помогает им подготовиться к навыкам, которые им понадобятся завтра.

GraphQL имеет очень удобочитаемую структуру и его легко понять. Учитывая широту реализаций в разных средах и языках программирования. Это означает, что спецификация GraphQL, вероятно, будет более универсально применимой, чем глубокое знание любого отдельного REST API.

Что касается React в качестве слоя просмотра, то это несомненный бонус. В отличие от языков шаблонов, которые не имеют информации о структуре вывода, структура компонентов, реализованная в React. Кроме того, Next.js поддерживает экспорт статических ресурсов для динамических элементов.

Статический экспорт означает, что, несмотря на то, что Next.js работает на сервере Node.js, вы можете экспортировать статический пакет, который обслуживается обычным HTTP-сервером. Это, в свою очередь, обеспечивает высокую производительность, высокий уровень безопасности, а также более низкую стоимость хостинга благодаря минимальному использованию ресурсов.

Еще одним преимуществом этой комбинации является гибкость фреймворка Next.js. Вместо того, чтобы навязывать свои собственные компоненты для всего, разработчики могут использовать популярные фреймворки Node.js, такие как Express или Koa, вместе с Next.js для своих внутренних функций.

Сборка из небольших функциональных компонентов соответствует философии NPM и JavaScript в целом. Лучше всего то, что все это необязательно, и большинство разработчиков, вероятно, не будут заменять маршрутизатор или другие компоненты.

Использование Next.js не лишает возможности богатой экосистемы, выросшей вокруг React.js, а это означает, что разработчики могут использовать любые компоненты и другие библиотеки для расширения своего приложения за пределы сайта, управляемого контентом, обсуждаемого в этой статье.

Добавление Redux, MobX State Tree или других решений для управления состоянием также может помочь разработчикам создавать сложные мастера форм и другие общие функции, используемые в веб-приложениях и сайтах, управляемых контентом. Кроме того, важно подчеркнуть, что сам протокол GraphQL не ограничивается передачей контента, а является коммуникационным протоколом общего назначения.

Недостатки использования GraphQL и Next.js

При разработке сайта первый вопрос должен заключаться в том, какие преимущества, если таковые имеются, дает техническое решение? В случае маркетинга сайта, ориентированного исключительно на контент, сайт, построенный с использованием этого стека, не обязательно дает какие-либо преимущества. Вам необходимо обосновать использование этой дополнительной сложности.

На самом деле, поскольку клиент будет отправлять клиенту больше информации, такой как библиотека JavaScript и многое другое, производительность может быть хуже, чем при традиционном методе доставки контента, управляемом сервером. Вместе с HTTP/2 и постоянно увеличивающейся производительностью JavaScript в браузерах эта проблема ухудшается, но никогда не исчезнет полностью.

Кроме того, хотя технологии JavaScript, NPM, React, JSX и т. д. знакомы многим разработчикам, они все еще новы для подавляющего большинства разработчиков, создающих сайты с такими системами управления контентом, как WordPress или Drupal. Это означает, что, несмотря на то, что Next.js значительно снижает начальный барьер входа, это не значит, что выбрать все это за один раз – тривиальная задача.

Системы управления контентом в целом выполняют гораздо больше задач, чем просто ввод и доставка контента. Управление макетами, управление формами и даже аналитика контента часто считаются сферой деятельности CMS. Ни одна из этих встроенных утилит не будет доступна при создании несвязанного сайта с любой технологией, поэтому вам необходимо принять это во внимание при оценке функциональности и рабочей нагрузки проекта, созданного с помощью несвязанного подхода.

Из-за особенностей Next.js разработка также будет иметь некоторые особенности. Разработчики должны помнить, что написанный ими JavaScript должен выполняться как на сервере, что иногда приводит к трудно обнаруживаемым ошибкам и проблемам с кэшированием, неслыханным в более традиционных реализациях.

Что касается производительности, если вы не выполняете кэширование на стороне сервера, вы создаете рабочую нагрузку, связанную с ЦП, на сервере. Несмотря на то, что движок V8, работающий под управлением Node.js, обладает характеристиками производительности мирового класса, а React 16 также улучшил производительность SSR, факт в том, что они никогда не смогут конкурировать с отправкой большого двоичного объекта HTML.

Вы можете настроить CDN или обратный прокси-сервер перед своим сервером Next.js для кэширования отображаемого на стороне сервера HTML, но это может привести к большим проблемам, поскольку клиент ожидает, что HTML будет соответствовать любому выводу API. Поэтому очистка кешей — это то, для чего вам нужно иметь стратегию, особенно если вы будете запускать установку с сотнями тысяч отдельных URL-адресов.

В целях безопасности Next.js и особенно экспортируемый статический HTML не добавляют никаких дополнительных последствий для безопасности. Но для GraphQL дело обстоит иначе. Хотя в архитектуре GraphQL нет серьезных недостатков безопасности, цепочка настолько прочна, насколько сильно ее самое слабое звено. Разработчики, создающие серверные части GraphQL, могут использовать некоторые ярлыки, которые приведут к утечке конфиденциальной информации из серверной части GraphQL.

В качестве альтернативы созданные запросы GraphQL могут позволить перегружаться сложными запросами, которые ставят сервер на колени. Это, в свою очередь, замедлит или полностью отключит API и остановит весь трафик, когда вы выполняете SSR с Next.js на сервере Node.js на лету.

Хотя SQL нельзя сравнивать с GraphQL, все же стоит учитывать, что любому вводу, который вы отправляете на серверную часть GraphQL, нельзя доверять. Тем более, что благодаря самоанализу GraphQL злоумышленники могут получить полное представление о возможностях вашей конечной точки GraphQL. Вот почему было бы важно предоставить только минимальные возможности общедоступной конечной точке GraphQL.

Вывод

Сочетание протокола GraphQL для связи и Next.js для разработки приложений с React.js для создания шаблонов является зрелым вариантом, который обеспечивает допустимый вариант для создания веб-сайтов. Конечно, для сайтов, которые в значительной степени полагаются на дополнительные функции CMS, на этом этапе, вероятно, следует обратить внимание на более традиционные подходы.

Для разработчиков этот стек имеет низкий барьер для входа, но в целом этот подход может не давать никаких реальных преимуществ по сравнению с большим двоичным объектом HTML, отображаемым на стороне сервера. С другой стороны, если вы хотите предоставить более богатую функциональность на внешнем интерфейсе, использование Next.js даст вам значительный старт с унифицированной архитектурой для вашего приложения.

Я с нетерпением жду возможности увидеть, как будет развиваться рынок, поскольку очевидно, что существует ряд конкурирующих технологий. И я уверен, что мы еще много чего увидим по этой теме.

— Яни Тарвайнен, 28.09.2017

Первоначально опубликовано на malloc.fi.