Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SSR以後の世界へ / techcamp05

B8e501d93b98a553abf0b5cee0c33503?s=47 yasaichi
November 20, 2018

SSR以後の世界へ / techcamp05

第5回開発合宿(2018/11/20)

B8e501d93b98a553abf0b5cee0c33503?s=128

yasaichi

November 20, 2018
Tweet

Transcript

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

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

  3. ピクスタでのRe-architectingの流れ 1. SSRのための基盤を導入する(今ここ) 2. RailsのViewをReactで書き直す 3. BFFを使って2とRailsを完全に切り離す 4. 愛すべき未来へ(cf. EXILE)

    !3 開発部中長期計画における "SoEとSoRの分離"のこと
  4. なぜSSR基盤を導入するのか • 一般的によく言われる目的: • SPAにおけるSEO対策のため • First Meaningful Paintの高速化のため •

    ピクスタでの目的: 既存のSEO面での要求を満たし ながら、エンジニアとデザイナーの職務の境界線を 変更するため !4
  5. 職務の境界線の変更 現在 デザイン マークアップ JavaScript バックエンド !5 目指したい状態 デザイン マークアップ

    JavaScript バックエンド ! デザイナー ! エンジニア ! デザイナー ! エンジニア こうすることでコンポーネントという 再利用可能な単位を導入できる
  6. 今回の目的: SSR以後の世界へ • 合宿で明らかにしたかったこと: 2の詳細 1. Reactで書き直すのはどの程度の労力がかかる? 2. コンポーネントの再利用はどれくらいできる? •

    最終的に明らかにしたいこと: 3の詳細 • 2ができていればスムーズに移行できる? !6
  7. Agenda   背景と目的 技術概要   やったこと   所感 !7

  8. SSR(Server Side Rendering)とは • 狭義の意味では、ブラウザ向けのコードをサーバー 側で実行し、HTMLを生成して返す手法のこと • 実現のための手段(Reactの場合) • Next.js:

    ZEIT製のWebアプリケーションフレーム ワークで、ReactのSSRを始め多くの機能を持つ • Hypernova: Airbnb製のSSR用のフレームワーク !8
  9. アーキテクチャの違い 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
  10. ピクスタではどちらを採用したか? • 次の理由から、Hypernovaを採用した • 直近は職務の境界線の変更にのみ集中したいため
 (≒ 同時に複数のことをやろうとすると失敗する) • Hypernova展開後の状態なら、Next.js等のBFF への移行もおそらく容易だろうと予想されるため

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

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

    Rails • フロントエンド: CoffeeScript(!), Browserify(!) !12
  13. 合宿前にやったこと 1. 技術スタックをモダンな?感じにする • CoffeeScript → TypeScript • Browserify →

    webpack 2. Hypernovaを導入する 3. 既存のSlimで書かれたViewを雑にReact側に移す !13
  14. 合宿中にやったこと 1. styled-components の導入 2. 雑に移したページの中から共通のコンポーネントを 切り出し、Atomic Designにしたがって整理する • 対応済み:

    <Map> • 対応中: <ContactUs>, <LazyLoadImg> !14
  15. ここで実際のサイト画面と対応する コードを見せる !15

  16. 参考: ディレクトリ構成(一部抜粋) !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の 構成を参考にしている
  17. Agenda   背景と目的   技術概要   やったこと 所感 !17

  18. 当初の疑問への回答 1. Reactで書き直すのはどの程度の労力がかかる? • 既存のViewを雑にReact側に移すのは楽 • 共通部分を抽出・整理するのが大変(特にCSS) 2. コンポーネントの再利用はどれくらいできる? •

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

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

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