Это четвертая часть короткой серии о моих попытках монетизировать припаркованные домены. Это лучше покрывает мои цели с рабочими процессами на основе Git и фактически начинает предоставлять код.
Я искал централизованное хранилище данных, из которого более 100 доменов могли бы получать контент. Безголовая CMS обязательна, один и тот же контент может отображаться на разных сайтах с совершенно разным форматированием и стилем. Как разработчик, решение на основе git было бы идеальным. Я не мог найти тот, который мне нравился, поэтому я начал создавать его.
Contentful — безголовая CMS
Contentful — ведущий поставщик безголовых CMS. Я использовал Contentful для некоторого контента в своем блоге, а также в местах, где я работал. Это упрощает создание сложных, многомерных данных, которые полностью локализованы. У Contentful даже есть бесплатное пространство сообщества, которое поддерживает довольно полный сайт.
Минусы:
- Допускается только одно свободное место, а стоимость дополнительных мест начинается от 489 долларов.
- Количество типов объектов или схем ограничено.
- Время отклика не удивительно, особенно для «CDN».
CMS на основе Netlify-Git
Я заинтригован обещаниями Netlify. Он основан на git, чтобы вписаться в остальную часть рабочего процесса, и вы даже можете хранить редактор с кодом.
Минусы:
- Тесно связан с сайтом Netlify.
- Нет простого способа смешивать и сочетать контент на сайтах.
Ghost — безголовая CMS
Призрак показался мне подходящим для блога. Но превратить один поток блогов в сотни блогов — это скорее работа для приложения.
Минусы:
- Парадигма ограниченной объектной модели.
- Нет простого способа смешивать и сочетать контент на сайтах.
Решение — создайте CMS на AWS
Намерение никогда не заключалось в том, чтобы писать какой-либо код, я думал, что, возможно, у меня получится пара ресурсов CDK или Cloudformation. Быть облачным инженером, разрабатывающим решение на AWS, всегда интересно. Если все сделано правильно, это может быть экономически эффективным и может масштабироваться бесконечно без каких-либо изменений или вмешательства человека. Использование AWS может быть быстрым и надежным с минимальными усилиями.
Начните с файлов экспорта контента
Как я уже сказал, у меня есть некоторый контент для блога в бесплатной учетной записи Contentful, и я хотел бы его использовать. Если я смогу экспортировать его, я смогу использовать свое бесплатное пространство сообщества для игры и тестирования Contentful с использованием другого контента. Contentful также имеет сильную объектную парадигму, на которую будет легко опираться.
Разбить его!
Чтобы использовать этот большой экспортный файл, я создал Contentful Reader. Учитывая один большой файл Contentful, он разбивает JSON на множество меньших файлов для каждого типа контента или записи. Читатель может обрабатывать файлы размером в ГБ и может обрабатывать 60+ записей в секунду, поэтому для обработки файла размером 1 ГБ с 500 тыс. записей потребуется менее 15 минут.
Собери это вместе
Эти файлы идеально подходят для фиксации в репозиторий git. Это позволяет вам применять все имеющиеся на рынке инструменты рабочего процесса git к вашим данным Contentful. Рабочие процессы на основе Git с данными CMS похожи на арахисовое масло и шоколад, они прекрасно сочетаются друг с другом.
Преимущества Git
- Легко поддерживать несколько параллельных ветвей или версий.
- Повышенная проверяемость.
- Легко исправить ошибки.
- Интегрируется с другими процессами разработки.
Динамо это динамит
Последний шаг между CMS и веб-страницей по-прежнему выигрывает от гибкости контента, хранящегося в базе данных. Одиночные git-файлы не могут поддерживать производительный GraphQL API.
Для этого мы обращаемся к DynamoDB и дизайну одной таблицы. Я использую денормализацию и гидратацию для создания структуры Dynamo, которая может легко соответствовать моим ожидаемым шаблонам запросов.
Данные неключевого поля в таблице очень похожи на данные в файлах JSON. Магия заключается в ключах, созданных для данных. Файлы JSON из репозитория используются для создания сложного ключа раздела, ключа сортировки и значений ключа GSI. Эти ключи упрощают получение данных, уже отформатированных так, как нам нужно.
Подавать это
Данные Dynamo можно легко обслуживать как через REST API, так и через AppSync GraphQL API. Данные хранятся в оптимизированном формате, так что при обслуживании данных практически не требуется обработки.
Из-за особенностей AppSync и его распознавателей маловероятно, что одна и та же Lambda сможет обслуживать как запросы REST, так и запросы GraphQL. Любая общая логика между ними будет перемещена в пользовательские модули JavaScript. У меня есть простой файл Cloudformation для создания собственного репозитория NPM и PIP с использованием AWS CodeArtifact.
Экономьте деньги с кэшем
С точки зрения потребителя данные Dynamo доступны только для чтения. Это означает, что мы можем легко внедрить перед ним дистрибутив Cloudfront с включенным кэшированием. Это может ограничить максимальное количество обращений к серверной части до нескольких в месяц, независимо от того, сколько трафика может генерировать сайт.
Оптимизация схемы Dynamo
Сначала давайте рассмотрим распространенное заблуждение, что DynamoDB не следует рассматривать как «бессхемную». Его следует рассматривать как мультисхему или гибкую схему. В одной таблице могут быть элементы, соответствующие разным схемам. Схема для этих элементов может быть не определена явно, но она есть, иначе данные будут бесполезны в API. Я настоятельно рекомендую определить вашу схему как можно более явно.
Оптимизация ключей для частей и агрегатов
В случае разбиения одного потока блога на несколько есть два важных соображения.
- Как используются части данных?
- Как агрегируются части данных?
Я все еще пробую разные вещи и моделирую, как все будет работать для эффективного импорта, обновления и обслуживания.
Часть 1 — Парковка за копейки
Часть 2 — SSL-сертификаты AWS
Часть 3 — Парадигма массового хостинга
