Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
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
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.8k
[Teaser] Type-Safe Lightweight DDD with Effect Schema
yasaichi
3
640
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
510
Effectで作る堅牢でスケーラブルなAPIゲートウェイ / Robust and Scalable API Gateway Built on Effect
yasaichi
9
2.6k
あるRailsエンジニアがビジネスリーダーに転身するまで
yasaichi
9
3.5k
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
510
Other Decks in Programming
See All in Programming
느린 네트워크와 저사양 디바이스 사용자를 위한 웹뷰 로딩 시간 개선기
kmkim
1
170
baseline으로 마이그레이션, 리팩토링 안전하게 맡기기
fornewid
1
870
PyConTW 2026 - AI Coding 不只是工具升級, 區域醫院醫療資訊系統協作開發與資訊團隊轉型實踐
cclai999
0
230
プロジェクトコードをキレイキレイしよう!暗黙的な参照を読み解く静的解析
ostk0069
0
200
Goコンパイラを作ってGoをもっと理解する / Build a Go compiler to better understand Go
ikura_hamu
0
120
複数ドメインを一つのアプリに統合するFlutterの設計と運用_FlutterKaigi2026登壇資料(須永高弘)
takahirosunaga
0
140
Inertia Rails: The One-Person Framework with React & Friends
skryukov
0
210
Optunaを作ったときにやりたかったこと、その後 (2026/10/16, Optuna Meetup #3)
iwiwi
4
1.4k
オーケストレーション記述言語 Katari
yukikurage
0
220
[2026-10-14](C)Re:ゼロから始める異世界生活〜始まりの終わりと終わりの始まり〜
tosite
0
300
React Native経験者が Flutterを30⽇間触って驚いたこと
3saito
0
140
高橋メソッドでCVE解説シリーズ 〜CVE-2026-112816〜
hakkadaikon
0
200
Featured
See All Featured
Design in an AI World
tapps
1
380
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
520
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.6k
Color Theory Basics | Prateek | Gurzu
gurzu
1
510
BBQ
matthewcrist
90
10k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
540
Visualization
eitanlees
153
17k
Six Lessons from altMBA
skipperchong
29
4.6k
Raft: Consensus for Rubyists
vanstee
143
7.8k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
203
77k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
650
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
440
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