Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
SSR以後の世界へ / techcamp05
yasaichi
November 20, 2018
Programming
3
1.3k
SSR以後の世界へ / techcamp05
第5回開発合宿(2018/11/20)
yasaichi
November 20, 2018
Tweet
Share
More Decks by yasaichi
See All by yasaichi
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
yasaichi
46
17k
Active Recordから考える次世代のRuby on Railsの方向性 / Directions for the next generation of Ruby on Rails: From the viewpoint of its Active Record
yasaichi
36
16k
ピクスタのエンジニアリングとCircleCI / Software Engineering with CircleCI at PIXTA
yasaichi
1
270
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?
yasaichi
132
77k
サービス開発の現場からOSSを生み出す思考技術 / genbaweb04
yasaichi
3
830
Capybaraで変更に強いE2Eテストを書く / TokyuRubyKaigi12
yasaichi
5
1.5k
今更始めるGo言語 / techcamp04
yasaichi
0
2.8k
とある企業のモバイル対応 / Rails Developers Meetup 2017
yasaichi
1
3.4k
テスト駆動開発と私 / TechBookWalk TDD
yasaichi
3
1.7k
Other Decks in Programming
See All in Programming
Jetpack Compose 完全に理解した
mkeeda
1
450
tidy_rpart
bk_18
0
580
Git Rebase
bkuhlmann
10
1.2k
Qiita Night PHP 2023
fuwasegu
0
10k
Most Valuable Bug(?) ~インシデント未遂から得た学び~
tatsumiakahori
0
150
ITエンジニア特化型Q&Aサイトteratailを 言語、DB、クラウドなど フルリプレイスした話
leveragestech
0
400
Refactor with using `available` and `deprecated`
417_72ki
3
380
監視せなあかんし、五大紙だけにオオカミってな🐺🐺🐺🐺🐺
sadnessojisan
2
1.4k
SwiftPMのPlugin入門 / introduction_to_swiftpm_plugin
uhooi
2
100
Functional Data Engineering - A Blueprint for adopting functional principles in data pipeline
vananth22
0
180
なぜRubyコミュニティにコミットするのか?
luccafort
0
310
T3 Stack and TypeScript ecosystem
quramy
3
740
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
120
29k
StorybookのUI Testing Handbookを読んだ
zakiyama
8
3.2k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
500
130k
The Pragmatic Product Professional
lauravandoore
21
3.4k
Raft: Consensus for Rubyists
vanstee
130
5.7k
Music & Morning Musume
bryan
37
4.6k
How to train your dragon (web standard)
notwaldorf
66
4.2k
Documentation Writing (for coders)
carmenintech
51
2.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
13
1.1k
GraphQLとの向き合い方2022年版
quramy
20
9.9k
Imperfection Machines: The Place of Print at Facebook
scottboms
254
12k
A Modern Web Designer's Workflow
chriscoyier
689
180k
Transcript
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にしたがって整理する • 対応済み:
<Map> • 対応中: <ContactUs>, <LazyLoadImg> !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