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
ファインディにおけるフロントエンド技術選定の歴史
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
puku0x
October 07, 2024
Technology
300
2
Share
ファインディにおけるフロントエンド技術選定の歴史
React×GraphQL特集 フロントエンド技術選定の裏側と、直面する技術的課題
puku0x
October 07, 2024
More Decks by puku0x
See All by puku0x
新メンバーのために、シニアエンジニアが環境を作る時代
puku0x
0
1.4k
Agent Skills 入門
puku0x
0
1.8k
ファインディにおけるフロントエンド技術選定の歴史
puku0x
2
2k
生成AIではじめるテスト駆動開発
puku0x
0
1.3k
実践!カスタムインストラクション&スラッシュコマンド
puku0x
2
3.2k
Nx × AI によるモノレポ活用 〜コードジェネレーター編〜
puku0x
0
1.6k
ファインディでのGitHub Actions活用事例
puku0x
9
3.8k
Findyの開発生産性向上への取り組み ~Findyフロントエンドの場合~
puku0x
0
480
Findyの開発生産性を上げるためにやったこと
puku0x
1
660
Other Decks in Technology
See All in Technology
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.5k
ServiceによるKubernetes通信制御ーClusterIPを例に
miku01
1
160
Modernizing Your HCL Connections Experience: Visual Report to chain, Profile Enhancements, and AI Integration
wannesrams
0
300
AI時代に越境し、 組織を変えるQAスキルの正体 / QA Skills for Transforming an Organization
mii3king
5
4.3k
2026年春のAgentCoreアプデ 細かいやつ全部まとめ
minorun365
3
220
AI時代に、 データアナリストがデータエンジニアに異動して
jackojacko_
0
720
10サービス以上のメール到達率改善を地道に継続的に進めている話 / Continue to improve email delivery rates across multiple services
yamaguchitk333
5
1.4k
大学職員のための生成AI最前線 :最前線を、AIガバナンスとして読み直すためのTips
gmoriki
2
4k
カオナビに Suspenseを導入するまで / The Road to Suspense at kaonavi
kaonavi
1
450
サービスの信頼性を高めるため、形骸化した「プロダクションミーティング」を立て直すまでの取り組み
stefafafan
1
260
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
580
拝啓、あの夏の僕へ〜あなたも知っているApp Runnerの世界〜
news_it_enj
0
240
Featured
See All Featured
Amusing Abliteration
ianozsvald
1
160
How STYLIGHT went responsive
nonsquared
100
6.1k
Balancing Empowerment & Direction
lara
6
1.1k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
1
34
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.4k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.3k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
340
We Have a Design System, Now What?
morganepeng
55
8.1k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
390
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
52k
Exploring anti-patterns in Rails
aemeredith
3
350
Transcript
ファインディにおける フロントエンド技術選定の歴史 1 2024/10/08 React×GraphQL特集 フロントエンド技術選定の裏側と、直⾯する技術的課題 ファインディ株式会社 フロントエンド テックリード 新福
宜侑 @puku0x
2 今年で7歳!
3 Findyのフロントエンド • Next.js + TypeScript + GraphQL • Jest、Testing
Library、Playwright(検証中) • Prettier、ESLint、Stylelint、Commitlint • Storybook、Style Dictionary、Figma • Nx(モノレポ管理ツール) • GitHub Actions
以前のフロントエンド構成 4
5 以前(〜2020年)のフロントエンド構成 • Railsモノリス上のReact ◦ React 16 ◦ バージョンの古いツール‧ライブラリ多数 ◦
クラスコンポーネント ◦ 型(Flow)はある、テストは無い ◦ 設計...? • モノリスのデメリット ◦ 軽微な修正でも⻑時間のCI待ちが発⽣ → 開発スピード低下
6 モノリス解体
7 解体後のフロントエンドはNext.jsを採⽤
8 Next.jsの採⽤理由 • 既存のReactの資産を活かしたい • SSRしたい • ビルド周りを任せたい • 最適化周りも任せたい
モノリス解体完了! (〜2021年5⽉) 9
GitHub上のアクティビティ数: 4倍 リリース回数: 9.1倍 PRクローズまでの速度: 35倍 10 Findyがモノリス環境をやめて得られたユーザへの爆速価値提供 https://note.com/ma3tk/n/na502374b6ad6
11 モノリス解体後のフロントエンドの課題 • バージョンの古いツール‧ライブラリ多数 • 型(Flow)はある、テストは無い
12 依存を減らす • 不要なパッケージの削除 • styled-components + classnames → Emotionに統⼀
• Redux関連 → @reduxjs/toolkit → に統⼀
13 開発基盤にNxを採⽤
14 Nxの採⽤理由 • 他のツールの設定を任せたい ◦ ESLintやJestなどがすぐに使える ◦ nx migrate による⾃動更新
• 今後の⼤規模化に備えたい ◦ nx affected による変更検知 ◦ Nx Cloudのリモートキャッシュ
15 Flow → TypeScript に移⾏ Flowの型注釈を削除 ↓ TypeScript(allowJs: true) ↓
TypeScript(strict: true)
16 TypeScriptの採⽤理由 • 型が欲しい • 移⾏のしやすさ • エディタとの相性 • 情報の豊富さ
開発基盤の刷新で フロントエンドが最⾼になっ... 17
...てない! 18
19 モノリス解体後のREST APIの課題 • そのページに使うデータ全部盛り ◦ マスタデータ ◦ ユーザーデータ パフォーマンスの懸念
• レスポンスが⼀定でない ◦ 同じ名称で型が全く異なる場合も ◦ TypeScript導⼊時は⼿動で型付け → つらい
20 REST API → GraphQLに移⾏ 社内ツールにGraphQL導⼊‧検証 ↓ プロダクトを⼀部GraphQL化 ↓ プロダクトを全GraphQL化
↓ 他のプロダクトに展開
21 GraphQLの採⽤理由 • 効率的なデータ通信 • スキーマ駆動 • graphql-codegenを含むエコシステム
22 フロントエンド共通の技術スタックたち ※SSRの要件の有無により使い分けています ※
23 今後のFindyフロントエンド • App Router(React Server Components) ◦ 新しいコンポーネント設計 ◦
ランタイム CSS-in-JS からの脱却 EmotionからCSS Modulesへの移⾏!React Server ComponentsのCSS対応 https://tech.findy.co.jp/entry/2024/09/09/090000
24 技術選定を振り返る • ユーザーのため ◦ 最速で価値を届けられるか? ◦ 良いユーザー体験が実現できるか? • ⾃分達のため
◦ チームに受け⼊れられるか? ◦ 良い開発者体験が期待できるか? • プロダクトのため ◦ 持続的な開発ができるか?
25 まとめ • 何のための技術選定か ◦ プロダクトとプロダクトに関わる⼈達のため • 重要なマインド ◦ 「当時はそれが正解だった」
• ⼩さくはじめる
技術選定に歴史あり 26
リスペクトを忘れずに 27
28 ツール選定といえば...
ツール選定のお供に 29 https://findy-tools.io/
We’re hiring! https://careers.findy.co.jp/ 30