Decoupled System with Turbo Frame

Slide 1

Slide 1 text

Decoupled System with Turbo Frame wtnabe Kanazawa.rb meetup #137 2024-01-20 (Sat)

Slide 2

Slide 2 text

目次 Headless CMS とは Headless CMS の導入はちょっとむずい発想を逆にしてみる〜 Headless Rails ? 〜構成例

Slide 3

Slide 3 text

まとめ Rails （いわゆるWeb MVC ）とCMS で得意領域が違う decoupled という考え方は採用しつつ、実現方法はHeadless CMS だけとは限らないより自由度の高い仕組み（汎用Web MVC ）をglue に、それぞれの得意を活かす rb な文脈なのでRails で進めるけどいわゆるWeb MVC なら通用する

Slide 4

Slide 4 text

Headless CMS とは

Slide 5

Slide 5 text

その昔 10 年ほど前にJamstack やHeadless CMS という言葉が流行った 2013 年 Contentful 創業 2014 年 Netlify 創業

Slide 6

Slide 6 text

伝統的な CMS コンテンツもデザインも全部一つの仕組みで実現するメリット WordPress など超メジャーな存在のおかげで制作依頼しやすい管理画面もなんとなく触ったことがあるデメリット例えばWordPress は安全性や互換性の維持がそこそこ大変力のあるホスティング業者に協力してほしくなる WordPress を魔改造してアップデートできなくなるとかあるある

Slide 7

Slide 7 text

Headless CMS の考え方コンテンツ管理とフロントの画面はユーザーも利用目的も違う → decoupled が重要なのでは？ ↓ コンテンツ管理だけを担う仕組みがHeadless CMS フロントエンドの進化をCMS から独立して進めることができる静的に出力すればパフォーマンス改善の選択肢も増える CMS がユーザーアクセスから分離されることで安全性も向上

Slide 8

Slide 8 text

Headless CMS の例サービスもOSS もある Contentful / CloudCannon / Prismic JekyllAdmin / NetlifyCMS microCMS / Kuroco collections

Slide 9

Slide 9 text

構成としてはこう Headless CMS サイトコンテンツユーザーここに作り込みを⾏う静的サイトで事前ビルド動的サイトで動的に取得概ねJSON

Slide 10

Slide 10 text

関係者を置くとこう Headless CMS サイトコンテンツユーザーコンテンツ担当デザイナーエンジニア概ねJSON ? デザインとコーディング JSON ⾊付け CMS の理解

Slide 11

Slide 11 text

あれ、システムの境界と担当領域の境界合ってなくない？

Slide 12

Slide 12 text

Headless CMS の導入はちょっとむずい

Slide 13

Slide 13 text

必要な準備 Headless CMS そのものの理解コンテンツの定義サイト上でJSON を取得してビルドする仕組み

Slide 14

Slide 14 text

困りごと作り込んでみないと使い勝手のいいCMS に仕上がるか分かりにくい書きながらデザイン込みのプレビューはやりにくい伝統的なCMS ならコンテンツ定義はコンテンツ担当とデザイナーで完結できるのにHeadless CMS はエンジニアがいないと困りがち

Slide 15

Slide 15 text

Headless CMS が向いているケースコンテンツはコンテンツのみに集中、デザインは度外視数千ページとか明らかに伝統的CMS の性能的に厳しいボリュームエンジニア兼デザイナ兼ライターが伝統的CMS を持ちたくない逆に向いているケースにマッチしない場合はコスパが悪いのでは？

Slide 16

Slide 16 text

とは言え機能的にCMS で十分なものをフルRails 開発もコスパが悪い Web 制作の領域なので制作の人の活躍の最大化を目指すべき

Slide 17

Slide 17 text

そこで逆に Headless CMS の位置に Rails を置いてみる

Slide 18

Slide 18 text

表に⾒えるサイト検索などシステム HTML HTML 断⽚ Rails ユーザー Turbo Frame 必要なパーツのみ Turbo Frame で必要なコンテンツを取得（JSON→DOM 変換不要）セキュリティや保守はホスティングの力量に期待

Slide 19

Slide 19 text

表に⾒えるサイト検索などシステム HTML HTML 断⽚ Rails ユーザーデザイナーエンジニアコンテンツ担当 Turbo Frame 必要なパーツのみ

Slide 20

Slide 20 text

担当領域が素直

Slide 21

Slide 21 text

フロントエンドで気にすること全体の構成、デザイン Turbo Frame 記法所定の位置に正しく所定のコードを貼ることデザイン（CSS ）

Slide 22

Slide 22 text

バックエンドで気にすること提供するHTML 断片に必要なデータ提供するHTML 断片 Turbo Frame に対するケア

Slide 23

Slide 23 text

構成例

Slide 24

Slide 24 text

サイト Netlify (Jekyll など) Heroku (Rails) ユーザー基本はこっち Netlify + Heroku インフラ管理ほぼ不要ユーザーは（Heroku 一本より）低レイテンシで快適 monorepo で開発でき、内製なら柔軟な対応が可能 Jekyll のページの増減、改修はRails よりカジュアル wtnabe/example-rails-and- jekyll-monorepo

Slide 25

Slide 25 text

サイト CMS Rails ユーザー基本はこっち CMS + Rails 更新は更新担当だけで可能 CMS は制作会社で、仕組みは内製のパターンも可 Rails 側は前ページと一緒

Slide 26

Slide 26 text

サイト CMS Rails SaaS ユーザーコンテンツ担当エンジニア何らかの業務担当基本はこっち CMS + Rails + SaaS glue としての Rails & Turbo Frame

Slide 27

Slide 27 text

まとめ Rails （いわゆるWeb MVC ）とCMS で得意領域が違う decoupled という考え方を踏襲しつつ、実現方法はHeadless CMS だけとは限らないより自由度の高い仕組み（汎用Web MVC ）をglue に、それぞれの得意を活かす