CMSとFrontned / cms-frontend

297a42b94a1bda236982ec1cd81089b6?s=47 mottox2
December 08, 2018

CMSとFrontned / cms-frontend

2018/12/08にFRONTEND CONFERENCE FUKUOKA 2018 (#fec_fukuoka)の登壇で使用した資料です。

297a42b94a1bda236982ec1cd81089b6?s=128

mottox2

December 08, 2018
Tweet

Transcript

  1. 3.
  2. 7.

    #fec_fukuoka CMSとは? • コンテンツ管理システム。(Content Management System) • ユーザーからHTMLやCSSに関しての知識を必要とせずページが編集・公 開できるようなシステム。 •

    開発者から⾒たら⼊⼒画⾯がリッチなCRUDアプリケーション。 • ⼀般的に、管理画⾯と公開される画⾯がモノリシックになっているアプリ ケーション。
  3. 10.

    #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
  4. 16.

    #fec_fukuoka 内製CMSのデメリット • エンジニアがある程度いることが前提にある。 • 実装⼯数が⼤きい。フロントとバックを分離したら更に⼯数が必要。 • コンテンツ⼊⼒画⾯が実装⼯数の⼤半をしめる。 • そもそも難しい。

    • ⾃由であるがゆえの要望が多くなりがち。 • 「〜できる?」→「やります」の流れでどんどんでかくなる。 • 新規メンバーの導⼊コスト。脆弱性の対応も⾃分で。
  5. 21.

    #fec_fukuoka Headless CMSの分類 1 2 API駆動系 Gitベース系 Gitでコンテンツを管理する⽅式。 Git上のコンテンツをいじる管理画⾯ を提供する。

    フロントエンドも同じリポジトリ内 で管理されることが多い。 CMSとフロントエンドが分離され る⽅式。 API経由でデータを受け渡す。 今⽇はこちら headlesscms.org https://headlesscms.org/about/
  6. 23.

    #fec_fukuoka Headless CMS WordPress 盖椚歗꬗ ؐؑـل٦آ 盖椚歗꬗ 8FC"1* ؐ ؑ

    ـ ل ٦ آ ٌ غ ؎ ٕ ، ف ٔ *P5ر غ ؎ أ CMSとは独⽴した開発が⾏える 開発する場所
  7. 25.

    #fec_fukuoka 初期コストを抑えつつ、継続的に開発できる WordPress 内製 CMS 初期コストは低いが、運⽤期間が⻑くなると 開発コストが⾼くなる 初期コストは⾼いが、運⽤期間が⻑くなると WordPressと⽐べ相対的に開発コストが低め Headless

    CMS フロントエンドのみの開発でいいので 初期コストが⽐較的低く 運⽤期間が⻑くなっても そんなに開発コストが変わらない *グラフはイメージ図です Ꟛ涪؝أز 麊欽劍꟦
  8. 31.

    #fec_fukuoka エンジニアから⾒たメリット • 他のサービス開発で使っているスタックで開発できる。 • プロダクトとスタックを揃えるとサイトの運⽤が⽚⼿間になりにくい。 • フロントエンド界隈で成熟した便利な概念を使える。 • Scoped

    CSS, ComponentベースでのUI構築。 • バックエンドと分離しておけば、後々部分的に差し替えられる。 • 開発環境も簡単に⽴ち開発速度を維持できる。GitHubにも載せられる。 • 普通のWebアプリケーション開発。 Headless CMSを使うとどうなるか?
  9. 33.

    #fec_fukuoka エンジニアから⾒たデメリット • JS⼒が問われる。 • SPA特有の苦しさがある。 • GoogleTagManager、計測、A/Bテストなど。 • イベントトラッキングは⾮常に仕込みやすい。

    • WordPressにあったような便利なプラグインはないので、基本⾃前で作る かnpmパッケージにお世話になる。 Headless CMSを使うとどうなるか?
  10. 39.

    #fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発からリリースまで120h。 • ほとんどの時間をリダイレクトや仕様の維持に。 • 約900記事のページをGatsbyJSでビルド。 • 全ページ数えると1600枚ぐらいのHTMLが出⼒されている。

    • デプロイが20分*から6~8分まで短縮された。 • ビジネス側には速度・セキュリティ⾯のメリットが刺さった。 事例1 *WordPressをECS上で運⽤していたためデプロイが⾮常に⻑かった。 概要
  11. 41.

    #fec_fukuoka WordPressのフロントエンドをReactにリプレース • 開発環境が `yarn develop` だけで⽴つようになった。 • 記事データは常に本番のWP REST

    APIから取得する。 • ビジネスの⼈がプルリクエスト投げてくれる出来事があった。 • 普通のReactアプリケーションとして開発できるので体験がよい。 • Netlifyでデプロイが完結するようになり、構成がシンプルになった。 • Lighthouseのパフォーマンススコアが50点台から90点台に。 事例1 いい点
  12. 48.

    #fec_fukuoka 現実的な⼀歩⽬ • WordPressでもWP REST APIを採⽤することでHeadless CMSとして使え るのでいい選択肢になりうる。 • 開発者として関わるのであれば、Monolithicで作り始めないこと。

    • 最初はHeadlessCMSで作って、ビジネスの数字がよくなったら独⾃CMS のバックエンドに差し替えるなどの⼿法を検討。 • Webアプリケーション開発における当たり前の⽅法で作りたい。