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
580
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
源内ハンズオン概要編
hideg
0
190
the container ship “Apple Silicon”@WWDC26 Recap -Japan-\(region).swift
shingangan
0
130
Cloudflare is Agents
chimame
0
170
Jindong: Introducing Declarative Haptics in Compose Multiplatform
l2hyunwoo
0
120
Claude CodeとAgentCore Gatewayを繋ぐ際の認証認可 / Authentication and authorization when connecting Claude Code with AgentCore Gateway
har1101
2
290
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
500
OpenSpecのproposalにbrainstormingを持たせてみた
tigertora7571
1
240
進化を続けるGo toolsの現在地 / The Current State of Ever-Evolving Go Tools
hond0413
0
230
実装をデザインガイドラインに追従させるための取り組み / 260731-dip-mosh-design-system
dachi023
0
980
仕様駆動開発へのトライを機に チームに適合する手法を模索し続けている話
freee
PRO
0
550
仕様書を書く前にハーネスを作る - Agent Native開発は「探索を速く、判定を固く」
gotalab555
4
1.7k
自動化したのに回らないテスト運用の壁ーAI時代の品質責任と生産性
mfunaki
1
140
Featured
See All Featured
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
430
Exploring anti-patterns in Rails
aemeredith
3
460
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
Practical Orchestrator
shlominoach
191
12k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
370
Evolving SEO for Evolving Search Engines
ryanjones
0
250
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2.1k
The Cult of Friendly URLs
andyhume
79
7k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
YesSQL, Process and Tooling at Scale
rocio
174
15k
The agentic SEO stack - context over prompts
schlessera
0
860
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
370
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