Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Decoupled System with Turbo Frame
Search
wtnabe
January 20, 2024
Programming
180
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Decoupled System with Turbo Frame
Kanazawa.rb meetup 137で話したTurbo Frameを使ってHeadless CMSとは異なる形で実現するDecoupledな仕組みについて
wtnabe
January 20, 2024
More Decks by wtnabe
See All by wtnabe
Rubyでもモノリポしたい - 調査、おわわり編 -
wtnabe
0
61
Ruby de Railway Oriented Programming
wtnabe
0
110
Bindanのススメ
wtnabe
0
65
そのオブジェクト、何を保証してくれますか? - GuideRailのススメ -
wtnabe
0
78
Effective Jekyll
wtnabe
0
98
5 min Jekyll/Liquid Plugin cooking
wtnabe
0
67
Ruby de Wasm
wtnabe
0
94
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
82
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
850
Other Decks in Programming
See All in Programming
言語を使う側から、作る側へ。 自作 Lisp で得た新たな気づき。
andpad
0
140
わからない話を追いかけたら、プログラミング言語を作る側にいた
ydah
2
290
音楽のための関数型プログラミング言語mimiumにおける多段階計算の活用
tomoyanonymous
1
380
Japan Community Day at Kubecon + CloudNativeCon Japan 2026: Learning Container Privilege Control by Building My Own Low-Level Container Runtime
ternbusty
1
110
【やさしく解説 設計編・中級 #1】一つの車に、運転手は一人 ~ある倉庫システムの事例から~
panda728
PRO
0
200
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
480
AWS DevOps AgentのAzure接続機能を検証して見えた活用法/Use Cases Verified for the AWS DevOps Agent's Azure Connectivity Feature
masakiokuda
0
180
GDG Korea Android: 2026 I/O Extended ~ What's new in Android development tools
pluu
0
200
5分で問診!Composer セキュリティ健康診断
codmoninc
0
770
SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7
tomoyakitaura
9
5.9k
改善しないと、タスクが回らない。 “てんこ盛りポジション” を引き継いだ情シスの、入社3ヶ月の業務改善録
krm963
0
230
ビデオ通話が繋がる0.2秒で何が起きているのか
supurazako
2
160
Featured
See All Featured
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
430
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
470
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.2k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.3k
BBQ
matthewcrist
89
10k
ラッコキーワード サービス紹介資料
rakko
1
4.1M
For a Future-Friendly Web
brad_frost
183
10k
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.5k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
400
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
280
Transcript
Decoupled System with Turbo Frame wtnabe Kanazawa.rb meetup #137 2024-01-20
(Sat)
目次 Headless CMS とは Headless CMS の導入はちょっとむずい 発想を逆にしてみる 〜 Headless
Rails ? 〜 構成例
まとめ Rails (いわゆるWeb MVC )とCMS で得意領域が違う decoupled という考え方は採用しつつ、実現方法はHeadless CMS だ
けとは限らない より自由度の高い仕組み(汎用Web MVC )をglue に、それぞれの 得意を活かす rb な文脈なのでRails で進めるけどいわゆるWeb MVC なら通用する
Headless CMS とは
その昔 10 年ほど前にJamstack やHeadless CMS という言葉が流行った 2013 年 Contentful 創業
2014 年 Netlify 創業
伝統的な CMS コンテンツもデザインも全部一つの仕組みで実現する メリット WordPress など超メジャーな存在のおかげで制作依頼しやすい 管理画面もなんとなく触ったことがある デメリット 例えばWordPress は安全性や互換性の維持がそこそこ大変
力のあるホスティング業者に協力してほしくなる WordPress を魔改造してアップデートできなくなるとかあるある
Headless CMS の考え方 コンテンツ管理とフロントの画面はユーザーも利用目的も違う → decoupled が重要なのでは? ↓ コンテンツ管理だけを担う仕組みがHeadless CMS
フロントエンドの進化をCMS から独立して進めることができる 静的に出力すればパフォーマンス改善の選択肢も増える CMS がユーザーアクセスから分離されることで安全性も向上
Headless CMS の例 サービスもOSS もある Contentful / CloudCannon / Prismic
JekyllAdmin / NetlifyCMS microCMS / Kuroco collections
構成としてはこう Headless CMS サイト コンテンツ ユーザー ここに作り込みを⾏う 静的サイトで事前ビルド 動的サイトで動的に取得 概ねJSON
関係者を置くとこう Headless CMS サイト コンテンツ ユーザー コンテンツ担当 デザイナー エンジニア 概ねJSON
? デザインと コーディング JSON ⾊付け CMS の理解
あれ、システムの境界と担当領域の境界 合ってなくない?
Headless CMS の導入はちょっとむずい
必要な準備 Headless CMS そのものの理解 コンテンツの定義 サイト上でJSON を取得してビルドする仕組み
困りごと 作り込んでみないと使い勝手のいいCMS に仕上がるか分かりにくい 書きながらデザイン込みのプレビューはやりにくい 伝統的なCMS ならコンテンツ定義はコンテンツ担当とデザイナーで 完結できるのにHeadless CMS はエンジニアがいないと困りがち
Headless CMS が向いているケース コンテンツはコンテンツのみに集中、デザインは度外視 数千ページとか明らかに伝統的CMS の性能的に厳しいボリューム エンジニア兼デザイナ兼ライターが伝統的CMS を持ちたくない 逆に向いているケースにマッチしない場合はコスパが悪いのでは?
とは言え 機能的にCMS で十分なものをフルRails 開発もコスパが悪い Web 制作の領域なので制作の人の活躍の最大化を目指すべき
そこで 逆に Headless CMS の位置に Rails を置いてみる
表に⾒える サイト 検索など システム HTML HTML 断⽚ Rails ユーザー Turbo
Frame 必要なパーツのみ Turbo Frame で必要なコンテンツを取得(JSON→DOM 変換不要) セキュリティや保守はホスティングの力量に期待
表に⾒える サイト 検索など システム HTML HTML 断⽚ Rails ユーザー デザイナー
エンジニア コンテンツ担当 Turbo Frame 必要なパーツのみ
担当領域が素直
フロントエンドで気にすること 全体の構成、デザイン Turbo Frame 記法 所定の位置に正しく所定のコードを貼ること デザイン(CSS ) <turbo-frame id="xxx"
src="https://xxx.xxx/xxxx"> </turbo-frame>
バックエンドで気にすること 提供するHTML 断片に必要なデータ 提供するHTML 断片 Turbo Frame に対するケア
構成例
サイト Netlify (Jekyll など) Heroku (Rails) ユーザー 基本はこっち Netlify +
Heroku インフラ管理ほぼ不要 ユーザーは(Heroku 一本よ り)低レイテンシで快適 monorepo で開発でき、内製 なら柔軟な対応が可能 Jekyll のページの増減、改修 はRails よりカジュアル wtnabe/example-rails-and- jekyll-monorepo
サイト CMS Rails ユーザー 基本はこっち CMS + Rails 更新は更新担当だけで可能 CMS
は制作会社で、仕組み は内製のパターンも可 Rails 側は前ページと一緒
サイト CMS Rails SaaS ユーザー コンテンツ担当 エンジニア 何らかの 業務担当 基本はこっち
CMS + Rails + SaaS glue としての Rails & Turbo Frame
まとめ Rails (いわゆるWeb MVC )とCMS で得意領域が違う decoupled という考え方を踏襲しつつ、実現方法はHeadless CMS だ
けとは限らない より自由度の高い仕組み(汎用Web MVC )をglue に、それぞれの 得意を活かす