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
SSR以後の世界へ / techcamp05
Search
Yuichi Goto
November 20, 2018
Programming
1.9k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SSR以後の世界へ / techcamp05
第5回開発合宿(2018/11/20)
Yuichi Goto
November 20, 2018
More Decks by Yuichi Goto
See All by Yuichi Goto
[Teaser] Type-Safe Lightweight DDD with Effect Schema
yasaichi
3
570
Google Cloud を用いたソフトウェア開発の内製化組織の早期立ち上げの実現 / Rapid Establishment of In-House Software Development Teams Using Google Cloud
yasaichi
1
1.7k
[EN] Robust and Scalable API Gateway Built on Effect
yasaichi
3
480
Effectで作る堅牢でスケーラブルなAPIゲートウェイ / Robust and Scalable API Gateway Built on Effect
yasaichi
9
2.5k
あるRailsエンジニアがビジネスリーダーに転身するまで
yasaichi
9
3.4k
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
yasaichi
50
23k
Active Recordから考える次世代のRuby on Railsの方向性 / Directions for the next generation of Ruby on Rails: From the viewpoint of its Active Record
yasaichi
38
22k
ピクスタのエンジニアリングとCircleCI / Software Engineering with CircleCI at PIXTA
yasaichi
1
490
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?
yasaichi
147
95k
Other Decks in Programming
See All in Programming
複数の Claude Code が"放置"されてしまう問題をCLI ダッシュボードを自作して解決した話
sumihiro3
1
680
AWS CDK を「作」ってみた 〜フルスクラッチで見えた CDK の裏側〜 / aws-cdk-from-scratch
gotok365
3
2.8k
改善しないと、タスクが回らない。 “てんこ盛りポジション” を引き継いだ情シスの、入社3ヶ月の業務改善録
krm963
0
260
2年かけて Deno に DOMMatrix を実装した話 / How I implemented DOMMatrix in Deno over two years
petamoriken
0
210
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
490
AI時代のPHPer生存戦略 ~「言語、もうなんでもよくない?」に本気で向き合う~
vivion
0
400
いまどきの Codex で開発する visionOS アプリの開発スタイルについて
karad
0
140
Building a Meta Ray-Ban display app
akkeylab
0
140
GDG Korea Android: 2026 I/O Extended ~ What's new in Android development tools
pluu
0
220
そこに3びきプロダクトがいるじゃろう——生成AI時代における“価値が届かない理由”の構造
kosuket
0
480
ドリフトを絶対に許さない(?)CDK運用 / CDK Ops with Zero Tolerance for Drifts (?)
akihisaikeda
1
180
楽しそうなつよつよエンジニアと目が死んでる僕/A brilliant engineer having a blast, and dead-eyed me.
3l4l5
2
180
Featured
See All Featured
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
650
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Deep Space Network (abreviated)
tonyrice
0
250
A Soul's Torment
seathinner
6
3.4k
So, you think you're a good person
axbom
PRO
2
2.1k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.9k
Scaling GitHub
holman
464
140k
How STYLIGHT went responsive
nonsquared
100
6.2k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
430
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
570
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
370
The World Runs on Bad Software
bkeepers
PRO
72
12k
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