SSR以後の世界へ Yuichi Goto (@_yasaichi) November 20, 2018 @ 第5回開発合宿成果発表

Agenda 背景と目的 　 技術概要 　 やったこと 　 所感 !2

ピクスタでのRe-architectingの流れ 1. SSRのための基盤を導入する（今ここ） 2. RailsのViewをReactで書き直す 3. BFFを使って2とRailsを完全に切り離す 4. 愛すべき未来へ（cf. EXILE） !3 開発部中長期計画における "SoEとSoRの分離"のこと

なぜSSR基盤を導入するのか • 一般的によく言われる目的: • SPAにおけるSEO対策のため • First Meaningful Paintの高速化のため • ピクスタでの目的: 既存のSEO面での要求を満たし ながら、エンジニアとデザイナーの職務の境界線を 変更するため !4

職務の境界線の変更 現在 デザイン マークアップ JavaScript バックエンド !5 目指したい状態 デザイン マークアップ JavaScript バックエンド ! デザイナー ! エンジニア ! デザイナー ! エンジニア こうすることでコンポーネントという 再利用可能な単位を導入できる

今回の目的: SSR以後の世界へ • 合宿で明らかにしたかったこと: 2の詳細 1. Reactで書き直すのはどの程度の労力がかかる？ 2. コンポーネントの再利用はどれくらいできる？ • 最終的に明らかにしたいこと: 3の詳細 • 2ができていればスムーズに移行できる？ !6

Agenda 　 背景と目的 技術概要 　 やったこと 　 所感 !7

SSR（Server Side Rendering）とは • 狭義の意味では、ブラウザ向けのコードをサーバー 側で実行し、HTMLを生成して返す手法のこと • 実現のための手段（Reactの場合） • Next.js: ZEIT製のWebアプリケーションフレーム ワークで、ReactのSSRを始め多くの機能を持つ • Hypernova: Airbnb製のSSR用のフレームワーク !8

アーキテクチャの違い Next.js !9 Hypernova Browser Next.js API Server (e.g. Rails) Data Sever-rendered
 HTML + assets Request data
 (if needed) Request page Browser Rails Hypernova Sever-rendered
 HTML HTML + assets Request SSR Request page

ピクスタではどちらを採用したか？ • 次の理由から、Hypernovaを採用した • 直近は職務の境界線の変更にのみ集中したいため
 （≒ 同時に複数のことをやろうとすると失敗する） • Hypernova展開後の状態なら、Next.js等のBFF への移行もおそらく容易だろうと予想されるため !10

Agenda 　 背景と目的 　 技術概要 やったこと 　 所感 !11

今回の題材 • https://www.bob-kamakura.com • お世話になっている美容師さんのWebサイトで、 yasaichiが開発・運用しているので遊びたい放題 • バックエンド: Ruby on Rails • フロントエンド: CoffeeScript(!), Browserify(!) !12

合宿前にやったこと 1. 技術スタックをモダンな？感じにする • CoffeeScript → TypeScript • Browserify → webpack 2. Hypernovaを導入する 3. 既存のSlimで書かれたViewを雑にReact側に移す !13

合宿中にやったこと 1. styled-components の導入 2. 雑に移したページの中から共通のコンポーネントを 切り出し、Atomic Designにしたがって整理する • 対応済み: • 対応中: , !14

ここで実際のサイト画面と対応する コードを見せる !15

参考: ディレクトリ構成（一部抜粋） !16 frontend/src !"" components # !"" atoms # # $"" FontAwesomeIcon.tsx # !"" molecules # # $"" Map.tsx # !"" organisms # # $"" ContactUs.tsx # $"" templates # $"" DefaultLayout.tsx !"" images !"" lib # $"" hypernova-react.ts !"" pages # !"" access.tsx # !"" contact-us # # $"" index.tsx # !"" index.tsx # $"" privacy_policy.tsx $"" typings $"" images.d.ts このへんはAtomic Designの 分け方を参考にしている このへんはNext.jsの 構成を参考にしている

Agenda 　 背景と目的 　 技術概要 　 やったこと 所感 !17

当初の疑問への回答 1. Reactで書き直すのはどの程度の労力がかかる？ • 既存のViewを雑にReact側に移すのは楽 • 共通部分を抽出・整理するのが大変（特にCSS） 2. コンポーネントの再利用はどれくらいできる？ • 少なくとも今回の題材ではあまりできなかった !18

示唆1 • 所感1から • 職務の境界線を変更すること"だけ"ならそこまで 難しくなさそう（∵ 移行作業は並列で実施できる） • 外部CSSやコンポーネントを抽出・整理する作業は スキルが必要なので進め方に工夫が必要そう !19

示唆2 • 所感2から • 物にもよるが、「共通コンポーネントを切り貼りして ページを作る」世界の実現はそもそも難しそう • とはいえ、デザイナーとの意思疎通の手段としての デザインシステム構築のために、コンポーネントの 共通化を進めるメリットはありそう !20

お疲れさまでした！ 成果物: https://www.bob-kamakura.com !21