Преимущества, которых я не осознавал, и болевые точки, которые я усвоил на собственном горьком опыте

Недавно я закончил свое первое независимое веб-приложение, используя WordPress в качестве бэкэнда и React в качестве интерфейса. Я пишу статью, которую хотел бы иметь в начале процесса.

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

Что такое безголовая CMS?

Короче говоря, это система управления контентом, такая как WordPress, Drupal или Contentful, которая отделена от внешнего интерфейса. Основное преимущество этого подхода заключается в том, что он не зависит от технологий, то есть интерфейсный веб-сайт может быть построен с использованием любых инструментов или языков, которые вам нравятся. Главный недостаток в том, что вам нужно управлять двумя веб-приложениями вместо одного.

Зачем вообще использовать CMS?

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

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

Наконец, что бы там ни было, люди не хотят меняться. Часто они предпочитают использовать уже знакомую CMS, чем тратить время на изучение новой или настраиваемой системы. Это одна из причин, по которой WordPress может продолжать процветать, даже если отрасль переходит на «автономные» или «несвязанные» системы CMS.

Каковы преимущества автономной или независимой CMS?

Для меня преимущества значительно перевешивают недостатки. Вот некоторые из самых полезных:

  • Безголовые или разделенные системы продвигают методологию гибкой работы, позволяя создателям контента и разработчикам работать одновременно. Это может сократить время выхода на рынок.
  • Он обеспечивает высокий уровень гибкости: создатели контента могут использовать свои любимые CMS, а разработчики - свои предпочтительные интерфейсные технологии. Напротив, решения «все в одном» заставляют всех использовать одну и ту же систему, и они часто могут чувствовать себя перегруженными, потому что пытаются предложить все «из коробки».
  • Данные можно легко перепрофилировать для любого количества каналов (мобильные приложения, умные часы, голосовые приложения и т. Д.), Таким образом, обеспечивая соответствие контента требованиям завтрашнего дня: разработчикам нужно только создавать новый интерфейс для каждого нового интерфейса. По той же причине несколькими веб-сайтами можно управлять с помощью одной CMS.
  • Системы CMS обычно основаны на облаке, что делает их хорошо масштабируемыми, в то время как контент обычно предоставляется через высокопроизводительную CDN (сеть доставки контента), что снижает риск DDOS-атак.

Какие недостатки?

На мой взгляд, основных недостатков всего два:

  • Во-первых, может быть более высокий барьер для входа с точки зрения знаний: разработчикам необходимо понимание как CMS (и языков, лежащих в ее основе), так и выбранных ими интерфейсных технологий.
  • Во-вторых, вы в конечном итоге управляете двумя веб-сайтами, а не одним, поэтому ваша рабочая нагрузка возрастает - по крайней мере, на начальном этапе.

Сколько есть вариантов?

Много! На момент написания headlesscms.org имел 30 вариантов CMS с открытым исходным кодом и 30 вариантов CMS с закрытым исходным кодом, перечисленных на его домашней странице. Этот список не является исчерпывающим, поскольку традиционные системы CMS, такие как WordPress, Drupal и Magento, теперь имеют разделенные параметры, но не включены.

В чем разница между «безголовой» и «несвязанной» CMS?

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

  • Развязанная система подготавливает контент для презентации, а затем отправляет его в среду доставки - она ​​«активна». Данные из серверной части публикуются где-нибудь, независимо от того, выполняются ли вызовы API или нет. Вот как это работает, если вы используете REST API WordPress или Drupal.
  • Безголовая система бездействует, пока не будет отправлен запрос на контент - она ​​является «реактивной». Данные из серверной части доступны только через вызовы API, поскольку они не имеют встроенного внешнего интерфейса или уровня представления. Так работает более современная CMS, такая как Contentful.

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

Напротив, традиционная монолитная CMS объединяет интерфейс и серверную часть на одном веб-сайте. Именно так традиционно работают поставщики CMS, такие как WordPress, и этот подход требует, чтобы интерфейс и серверная часть были написаны на одном языке (в большинстве случаев, PHP).

Мне нужно два домена?

Это самое простое и гибкое решение. Если вы используете PHP для серверной части и фреймворк JavaScript, такой как React, для интерфейса, вам, скорее всего, потребуются полностью отдельные службы хостинга.

Но даже в противном случае шаги, которые могут позволить вам объединить интерфейс и серверную часть в одном домене (например, использование «псевдонима» на вашем веб-сервере), также могут снизить некоторую гибкость, которая заставила вас выбрать развязанную архитектуру в во-первых, не позволяя вам легко переключить интерфейс или серверную часть позже.

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

Обоим ли сайтам нужен сертификат SSL?

Сайт с SSL не может получать данные с сайта без сертификата SSL без специального разрешения, данного каждым отдельным пользователем. В этом случае Google Chrome заблокирует любые страницы с данными для выборки, используя не очень полезную фразу «Произошла непредвиденная ошибка». Это вызвало у меня головную боль в моем собственном проекте, поэтому я надеюсь, что вы сможете избежать той же ошибки!

Должен ли я дезинфицировать мои данные выборки?

Скорее всего, вы в конечном итоге будете использовать dangerouslySetInnerHTML для синтаксического анализа входящей разметки HTML, поэтому вам следует очистить входящие данные выборки. Использование этого свойства без проведения достаточных проверок может подвергнуть ваш сайт атакам межсайтового скриптинга (XSS) - вот почему это опасно!

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

Как я могу очистить мои данные выборки?

Если вы создаете приложение на JavaScript, одно простое и эффективное решение - это модуль узла XSS. Вы можете установить его, набрав npm i -s xss в терминале, а затем просто импортируйте его в любой файл JavaScript, в котором вы хотите очистить данные HTML:

import xss from 'xss';

Допустим, мы хотели очистить данные HTML в переменной content. Мы можем просто использовать xss как функцию и передать соответствующую переменную следующим образом:

<div dangerouslySetInnerHTML={{ __html: xss(content) }} />

Мне нравится этот модуль узла за его простоту - это всего лишь одна строка кода и трехсимвольный метод - но есть и другие варианты: два популярных модуля узлов для очистки данных - это DOMPurify и XSS-фильтры.

Как мне защитить секретные данные, хранящиеся в коде внешнего интерфейса?

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

Лучшее решение зависит от того, какие технологии вы используете для развертывания бессерверного приложения. Например, использование Netlify позволит вам настроить шлюзы API, используя его собственные Лямбда-функции. Если ваш хост не предлагает ничего подобного, вам, возможно, придется добавить серверный код в свое приложение.

Если я использую независимую CMS, что мне делать со слоем внешнего интерфейса?

Я все еще обдумываю этот вопрос для своего проекта WordPress-React. Я не полагаюсь на встроенный интерфейс WordPress ни для чего другого, кроме получения данных JSON и доступа к REST API, поэтому я рассматриваю необходимость входа в систему для доступа ко всем данным в интерфейсе WordPress.

В моем случае в интерфейсе WordPress нет конфиденциальных данных, которые меня беспокоят, но ограничение доступа ко всему, что есть, добавит еще один уровень защиты, а также предотвратит случайный выбор сканерами поисковых систем вверх дублированный контент. Если кто-нибудь знает, что делать с оставшимся слоем презентации CMS, дайте мне знать в комментариях!

Заключение

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

Если вам интересно узнать больше о моей конкретной комбинации (WordPress и React), ознакомьтесь с моим руководством Как создать современное веб-приложение с помощью WordPress и React. В нем есть множество фрагментов PHP и React, которые должны быть полезны любому, кто впервые приближается к этой комбинации технологий.

И если у вас есть мнение о движении к автономным / независимым системам управления контентом, я хотел бы услышать его в комментариях.