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
puku0x
October 07, 2024
Technology
2
230
ファインディにおけるフロントエンド技術選定の歴史
React×GraphQL特集 フロントエンド技術選定の裏側と、直面する技術的課題
puku0x
October 07, 2024
Tweet
Share
More Decks by puku0x
See All by puku0x
実践!カスタムインストラクション&スラッシュコマンド
puku0x
0
420
Nx × AI によるモノレポ活用 〜コードジェネレーター編〜
puku0x
0
1.2k
ファインディでのGitHub Actions活用事例
puku0x
9
3.4k
Findyの開発生産性向上への取り組み ~Findyフロントエンドの場合~
puku0x
0
430
Findyの開発生産性を上げるためにやったこと
puku0x
1
610
Angularコーディングスタイルガイドはいいぞ
puku0x
1
360
Nx CloudでCIを爆速にした話
puku0x
0
880
Findyのフロントエンド設計刷新を通して得られた技術的負債との向き合い方
puku0x
1
1.8k
最高の開発体験を目指して 〜Findyのフロントエンド設計刷新〜
puku0x
0
870
Other Decks in Technology
See All in Technology
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
180
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
180
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
10k
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.6k
La gouvernance territoriale des données grâce à la plateforme Terreze
bluehats
0
180
DroidKaigi 2025 Androidエンジニアとしてのキャリア
mhidaka
2
310
「Linux」という言葉が指すもの
sat
PRO
4
140
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
580
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
430
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
290
研究開発と製品開発、両利きのロボティクス
youtalk
1
530
Webブラウザ向け動画配信プレイヤーの 大規模リプレイスから得た知見と学び
yud0uhu
0
230
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
4k
How STYLIGHT went responsive
nonsquared
100
5.8k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Designing for humans not robots
tammielis
253
25k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
The Invisible Side of Design
smashingmag
301
51k
Making Projects Easy
brettharned
117
6.4k
It's Worth the Effort
3n
187
28k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Building Applications with DynamoDB
mza
96
6.6k
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