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
CMSとFrontned / cms-frontend
Search
mottox2
December 08, 2018
Technology
12
1.9k
CMSとFrontned / cms-frontend
2018/12/08にFRONTEND CONFERENCE FUKUOKA 2018 (#fec_fukuoka)の登壇で使用した資料です。
mottox2
December 08, 2018
Tweet
Share
More Decks by mottox2
See All by mottox2
もう一歩進めたい OG画像の動的生成
mottox2
7
1.6k
なぜコピペで使うコンポーネント集を利用するのか?
mottox2
8
6.9k
UIコンポーネントライブラリをうまく使うためにできること / components-with-designer
mottox2
7
3.8k
Figma Plugin公開までの壁を乗り越える
mottox2
2
2.9k
Puppeteerでつくる画像と動画 / images and videos made with puppeteer
mottox2
0
630
手触りのよいウェブを考える / better-mobile-web
mottox2
3
1.7k
組織と権限とSlack App / slack-app-with-roles
mottox2
1
610
SSRを避けるためにやっていること / ssr-alternative
mottox2
9
3.1k
JSXでつくる宣言的UIなプレゼンテーション / jsx-presentation
mottox2
7
33k
Other Decks in Technology
See All in Technology
スケールし続ける事業とサービスを支える組織とアーキテクチャの生き残り戦略 / The survival strategy for Money Forward’s engineering.
moneyforward
0
230
SpiderPlus & Co. エンジニア向け会社紹介資料
spiderplus_cb
0
400
Storage Browser for Amazon S3を触ってみた + α
miura55
0
100
Fabric 移行時の躓きポイントと対応策
ohata_ds
1
120
TSKaigi 2024 の登壇から広がったコミュニティ活動について
tsukuha
0
180
いまからでも遅くないコンテナ座学
nomu
0
200
Fearsome File Formats
ange
0
550
20241218_マルチアカウント環境におけるIAM_Access_Analyzerによる権限管理.pdf
nrinetcom
PRO
3
150
ハイテク休憩
sat
PRO
2
190
型情報を用いたLintでコード品質を向上させる
sansantech
PRO
2
220
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
nihonbuson
3
1.4k
AIエージェントに脈アリかどうかを分析させてみた
sonoda_mj
2
130
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Agile that works and the tools we love
rasmusluckow
328
21k
Speed Design
sergeychernyshev
25
720
Building Applications with DynamoDB
mza
92
6.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3.1k
RailsConf 2023
tenderlove
29
960
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.7k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
2
160
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Building Adaptive Systems
keathley
38
2.3k
Transcript
& Frontend CMS Frontend Conference Fukuoka 2018 @mottox2 /
TypeScript, React, Gatsby, Ruby on Rails エンジニアの登壇を応援する会 write-blog-every-week, JS Ninja
Gatsby, ReactNative, Nuxt お仕事 コミュニティ OSS
None
#fec_fukuoka 今⽇のターゲット • WordPressを選択して後々後悔したことのある⼈ • ウェブサイト開発でもモダンなフレームワークを使いたい⼈ • 継続的にメンテナンスできるウェブサイト開発を⽬指したい⼈
#fec_fukuoka Headless CMSを採⽤して 幸せなフロントエンド開発を⽬指す 今⽇のお話
#fec_fukuoka 今⽇話すこと • 従来のCMSでの開発の話。 • Headless CMSの話。 • Headless CMSを採⽤した開発の実例。
• 現実的な⼀歩⽬の話。
#fec_fukuoka CMSとは? • コンテンツ管理システム。(Content Management System) • ユーザーからHTMLやCSSに関しての知識を必要とせずページが編集・公 開できるようなシステム。 •
開発者から⾒たら⼊⼒画⾯がリッチなCRUDアプリケーション。 • ⼀般的に、管理画⾯と公開される画⾯がモノリシックになっているアプリ ケーション。
#fec_fukuoka CMSでの開発、⾟い
#fec_fukuoka CMSでの開発、なんで⾟いんだっけ?
#fec_fukuoka WordPress • 最も普及しているCMS。2003年にリリース。 • 世界のWebサイトのうち32.4%を占めるサイトがWordPress製。* • 簡単インストールに対応しているホスティングサービスが多い。 • ⼈⼝が多いため、テーマやプラグインが充実している。
• 今⽇のコンテキストでは「⼀般的なCMS」の代表例としてWordPressを取 り上げます。 *Usage of content management systems for websites https://w3techs.com/technologies/overview/content_management/all
#fec_fukuoka WordPressのメリット • サーバーにインストールするだけでサイトが⽴ち上がる。 • プログラミング知識がなくても⽴ち上げが簡単。 • テーマや拡張機能が豊富に揃っている。 • ⽇本語でも情報にすぐたどり着ける。
#fec_fukuoka WordPressのデメリット • JavaScriptではないがフロントエンドエンジニアが担当するケースが散⾒ される。 • カスタマイズしたいときはPHP/WordPress APIを使って編集する。 • セキュリティ的な不安がある。
• CMSや拡張機能の脆弱性を狙った攻撃が横⾏している。 1
#fec_fukuoka WordPressのデメリット • GitHubなどのフローに乗せるには⼀⼯夫必要。 • 開発環境も作るのにも苦労あり。 • 開発者がWebアプリケーションのテンションで作ろうとするとコストがバ カ⾼くなりがち。 •
移⾏するのもそれなりに⼤変。 • ⼀⾔でいうと開発者としては⾟いということ。 2
#fec_fukuoka 内製CMS • 内製で作るブログ管理やコンテンツ管理ツールもCMS。 • ⾃由度は⾼い。 • 今⽇はモノリスかマイクロかは論じません。
#fec_fukuoka 内製CMSのメリット • 開発スタックを⾃分で決められる。仕様の⾃由度が⾼い。 • Webアプリケーション開発の知識があれば作れる。 • 開発フローもGitHubに乗せられる。インフラもコード管理も。
#fec_fukuoka 内製CMSのデメリット • エンジニアがある程度いることが前提にある。 • 実装⼯数が⼤きい。フロントとバックを分離したら更に⼯数が必要。 • コンテンツ⼊⼒画⾯が実装⼯数の⼤半をしめる。 • そもそも難しい。
• ⾃由であるがゆえの要望が多くなりがち。 • 「〜できる?」→「やります」の流れでどんどんでかくなる。 • 新規メンバーの導⼊コスト。脆弱性の対応も⾃分で。
#fec_fukuoka 涪؝أز 麊欽劍 初期コストのギャップが⼤きい WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると 開発コストが⾼くなる 初期コストは⾼いが、運⽤期間が⻑くなると
WordPressと⽐べ相対的に開発コストが低め 初期コストのギャップ 最終的にはどちらも⾟い *グラフはイメージ図です
#fec_fukuoka どっちも⾟いので 結果としてWordPressが選択されがち
#fec_fukuoka 現代のソリューション Headless CMS
#fec_fukuoka Headless CMSとは? • コンテンツの表⽰部分を持たず、管理画⾯とコンテンツの配信⽤APIを持 つCMS。 • フロントエンドは何でもよい。Webアプリケーションでもスマホアプリで もIoTデバイスでも。
#fec_fukuoka Headless CMSの分類 1 2 API駆動系 Gitベース系 Gitでコンテンツを管理する⽅式。 Git上のコンテンツをいじる管理画⾯ を提供する。
フロントエンドも同じリポジトリ内 で管理されることが多い。 CMSとフロントエンドが分離され る⽅式。 API経由でデータを受け渡す。 今⽇はこちら headlesscms.org https://headlesscms.org/about/
#fec_fukuoka CMSとは独⽴した開発が⾏える Headless CMS WordPress 盖椚歗 ؐؑـل٦آ 盖椚歗 8FC"1* ؐ
ؑ ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ
#fec_fukuoka Headless CMS WordPress 盖椚歗 ؐؑـل٦آ 盖椚歗 8FC"1* ؐ ؑ
ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ CMSとは独⽴した開発が⾏える 開発する場所
#fec_fukuoka CMSもフロントエンドも⾃由に選べる Headless CMS Web Frontend React (Gatsby) Vue (Nuxt)
React (Next) Vue (Gridsome) etc Headless CMS or or or or
#fec_fukuoka 初期コストを抑えつつ、継続的に開発できる WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると 開発コストが⾼くなる 初期コストは⾼いが、運⽤期間が⻑くなると WordPressと⽐べ相対的に開発コストが低め Headless
CMS フロントエンドのみの開発でいいので 初期コストが⽐較的低く 運⽤期間が⻑くなっても そんなに開発コストが変わらない *グラフはイメージ図です 涪؝أز 麊欽劍
#fec_fukuoka 例) Contentful ManagedなHeadless CMS
#fec_fukuoka 例) strapi OSSのHeadless CMS
#fec_fukuoka 例) WP REST API WordPressでも Headless CMS的な使い⽅できます WordPress 4.7からコアに採⽤
#fec_fukuoka 例) Shopify API ShopifyでもAPIを使って Headless CMS的な使い⽅できます
#fec_fukuoka Headless CMS登場の時代背景 • 表⽰端末の多様化。 • Web周辺ツールの改善。(検索・分析・フォーム最適化・課⾦等) • アプリケーション分割の⾵潮。 •
SPA開発の⼀般化・開発資産の蓄積。
#fec_fukuoka エンジニアから⾒たメリット • 他のサービス開発で使っているスタックで開発できる。 • プロダクトとスタックを揃えるとサイトの運⽤が⽚⼿間になりにくい。 • フロントエンド界隈で成熟した便利な概念を使える。 • Scoped
CSS, ComponentベースでのUI構築。 • バックエンドと分離しておけば、後々部分的に差し替えられる。 • 開発環境も簡単に⽴ち開発速度を維持できる。GitHubにも載せられる。 • 普通のWebアプリケーション開発。 Headless CMSを使うとどうなるか?
#fec_fukuoka ビジネスサイドから⾒たメリット • 実装・計測などの⾃由度が⾼く、戦略的にサイトを成⻑させられる。 • 管理画⾯のバグや障害で消耗しない。 • 速度の最適化をやりやすい。 • 謎プラグイン導⼊がしにくく遅くしにくい。あとは実装次第。
ServiceWorker対応など • 速度を上げるとサイトの数字がよくなるなどの話もある。 • 採⽤で強い⼈が集まる可能性がある。 Headless CMSを使うとどうなるか?
#fec_fukuoka エンジニアから⾒たデメリット • JS⼒が問われる。 • SPA特有の苦しさがある。 • GoogleTagManager、計測、A/Bテストなど。 • イベントトラッキングは⾮常に仕込みやすい。
• WordPressにあったような便利なプラグインはないので、基本⾃前で作る かnpmパッケージにお世話になる。 Headless CMSを使うとどうなるか?
#fec_fukuoka ビジネスサイドから⾒たデメリット • プラグイン導⼊で済んだものに対して、いちいちエンジニアに変更を求め ないといけない。(WordPressと⽐較した場合のデメリット) • 管理画⾯のカスタマイズにHeadless CMSの縛りがある。 • WordPressでは簡単なことができないことがある。
• ホスティング型のHeadless CMSは⾼い。 Headless CMSを使うとどうなるか?
#fec_fukuoka 本当にできるの?
#fec_fukuoka 開発事例
#fec_fukuoka WordPressのフロントエンドをReactにリプレース 事例1 https://kobit.in
#fec_fukuoka WordPressのフロントエンドをReactにリプレース 事例1 Headless CMS Frontend React (Gatsby) WP REST
API Webhook WordPress
#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発からリリースまで120h。 • ほとんどの時間をリダイレクトや仕様の維持に。 • 約900記事のページをGatsbyJSでビルド。 • 全ページ数えると1600枚ぐらいのHTMLが出⼒されている。
• デプロイが20分*から6~8分まで短縮された。 • ビジネス側には速度・セキュリティ⾯のメリットが刺さった。 事例1 *WordPressをECS上で運⽤していたためデプロイが⾮常に⻑かった。 概要
#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 早くしてほしいというビジネスからの要望。 • 開発環境⽴てるのも、デプロイも⾯倒という不満。 • プロダクトでReactを使っていること。 • このサイトとは別にWordPressがあってそちらで検証。
事例1 導⼊の経緯
#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発環境が `yarn develop` だけで⽴つようになった。 • 記事データは常に本番のWP REST
APIから取得する。 • ビジネスの⼈がプルリクエスト投げてくれる出来事があった。 • 普通のReactアプリケーションとして開発できるので体験がよい。 • Netlifyでデプロイが完結するようになり、構成がシンプルになった。 • Lighthouseのパフォーマンススコアが50点台から90点台に。 事例1 いい点
#fec_fukuoka WordPressのフロントエンドをReactにリプレース • 最初はデザインリニューアルも同時にやろうかと思ったが断念。 • スコープでかすぎて終わる未来が⾒えなかった。 • JSXに書き換えるのがしんどい。 • 治安の悪いCSSをコンポーネントに収める作業。
• デプロイが6~8分。もう少し短くなると嬉しい。 • フレームワークのコアの改善を待つ。 事例1 つらい点
#fec_fukuoka Headless CMSを利⽤したブログの新規構築 事例2 https://mottox2.com
#fec_fukuoka Headless CMSを利⽤したブログの新規構築 事例2 Headless CMS Frontend React (Gatsby) Web
API Webhook esa.io
#fec_fukuoka Headless CMSを利⽤したブログの新規構築 • 開発からリリースまで4h。 • esa.io(情報共有ツール)をHeadless CMSとして使⽤。 • APIの利⽤制限があるSaaSでも静的サイトとしてビルドすれば回避可能。
• Gatsbyのキャッチアップ、バージョンアップテストに使⽤。 • GitHub: https://github.com/mottox2/website 事例2
#fec_fukuoka 銀の弾丸ではありません
#fec_fukuoka 銀の弾丸ではない • デメリットもあるので銀の弾丸ではないがBetterな選択肢。 • 開発者が関わりだした時点でフロント/バックの分離を検討する。 • 内製に差し替えるコストも低いので後から移⾏可能。 • フロントエンドの⼈としてはいい選択肢。
• いつでも変えられるという安⼼感が重要。捨てやすく。
#fec_fukuoka 現実的な⼀歩⽬ • WordPressでもWP REST APIを採⽤することでHeadless CMSとして使え るのでいい選択肢になりうる。 • 開発者として関わるのであれば、Monolithicで作り始めないこと。
• 最初はHeadlessCMSで作って、ビジネスの数字がよくなったら独⾃CMS のバックエンドに差し替えるなどの⼿法を検討。 • Webアプリケーション開発における当たり前の⽅法で作りたい。
#fec_fukuoka Webは着実に進化しています。 Headless + 現代のフロントエンド技術で幸せな開発を!
#fec_fukuoka @mottox2 @mottox2 / Frontend Conference Fukuoka 2018 Thank you!