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
DMMアカウントサービスのフロントエンド改善
Search
okmttdhr
June 18, 2021
Programming
2
760
DMMアカウントサービスのフロントエンド改善
okmttdhr
June 18, 2021
Tweet
Share
More Decks by okmttdhr
See All by okmttdhr
フロントエンドエコシステムで効率化する組織開発
okmttdhr
4
9.6k
スケーラブル CI/CD with Nx モノレポ
okmttdhr
5
2.3k
LambdaとDynamoDBでIoTバックエンド開発
okmttdhr
0
120
Other Decks in Programming
See All in Programming
NPOでのDevinの活用
codeforeveryone
0
850
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
2.2k
PicoRuby on Rails
makicamel
2
130
XP, Testing and ninja testing
m_seki
3
250
Is Xcode slowly dying out in 2025?
uetyo
1
280
Deep Dive into ~/.claude/projects
hiragram
14
2.6k
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
190
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
170
10 Costly Database Performance Mistakes (And How To Fix Them)
andyatkinson
0
400
技術同人誌をMCP Serverにしてみた
74th
1
650
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
180
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Statistics for Hackers
jakevdp
799
220k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Designing Experiences People Love
moore
142
24k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
690
Building Adaptive Systems
keathley
43
2.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Transcript
DMMアカウントサービスのフロントエンド改善
自己紹介 2020年10月入社 DMMプラットフォーム事業本部エンジニア 相席食堂にハマっている
テーマ: DMMアカウントサービスのフロントエンド改善 半年ほど前からフロントエンドに対する技術的な改善プロジェクトがスタート どのような課題・理想があり、それに対してどう技術的なアプローチをしているのかを 話します
アジェンダ アカウントサービスの理想 アカウントサービスの課題 既存の機能の担保する(守り) 高速&安心なUI開発に変えてゆく(攻め)
プラットフォーム事業本部とは DMMの中でも横断的な機能を提供する部署 トップページ、認証、決済、ヘッダー、フッター、etc アカウントサービスは認証認可を担当するアプリケーション いわゆるログイン・登録機能
プラットフォーム事業本部とは =>チームに閉じた効率化はもちろんだが、各事業部が簡単に機能を使 えるようにすることで、組織全体の効率化につながるのが特徴
どういう状態が理想か? アカウントサービスのやりたいことはたくさん 様々なアプリケーション: DMMには50以上の事業がある。DMMログインを使いたい が、「デザインはサービスに合うように変えて欲しい」のような要望がある 様々なプラットフォーム: SPAで使いたい、PWAで使いたい、Electronで使いたい、TV で使いたい、PS5で使いたい、アプリで使いたい、独自ログインを提供したい、、 様々なユースケース: SNSログインしたい、他社からDMMアカウントでOIDCしたい、多
要素認証を実装してほしい =>これらに素早く対応できる、拡張性・ポータビリティの高いソフト ウェアにしておきたい
どういう状態が理想か? ソフトウェアとして 変更がしやすい テスタビリティが高い ビジネスとして 事業部に簡単に提供できる 施策の素早い検証と改善が行える
どういう状態が理想か? =>変更容易性が高く、素早く安心してアプリケーションをデプロイで きる状態
既存の技術スタック Node.js+Expressのサーバーサイドアプリケーション もともと巨大なPHPモノリスから 切り出されて再実装された 基本はテンプレートエンジン。要所でReactを使用(webpack) Node.jsバックエンドをBFFとし、認証認可・会員・社内基盤等のサービス、APIとやり 取り(Javaが多い) 上記の事情から、Node.jsのバックエンドに多くのビジネスロジック ECS上で動く。要所でLambdaやRedisを使用
既存の技術スタック =>Node.js+Express =>フロントエンドの持ち物 = いわゆるフロントエンド+BFF
既存アプリケーションの技術的な課題を洗い出し 例 依存モジュールの更新ができていない(メジャーバージョンだけで50以上) 使用しているテンプレートエンジン( ect )がメンテされていない CSSがスコープ化されておらず、また、影響範囲の大きな書き方がされている 多くのユニットテストがリクエスト単位での大きなテストで書かれており、アーキテク チャとあわせてテスト設計されていない UIとロジックが密結合していて開発しづらく、テストもされていない
E2Eテストが壊れやすくメンテもされていない ブラウザのエラーを拾えていない (歴史的経緯により)多くの独自 node_modules 全体的に古い書き方のコード( cjs , Class Component , jQuery etc)
既存アプリケーションの技術的な課題を洗い出し =>それぞれの課題同士に依存関係がありそう
既存アプリケーションの技術的な課題の優先度付け
既存アプリケーションの技術的な課題の優先度付け 課題を洗い出し、優先度をつけて取り組むことに。 例えば、 [優先] 以降の開発効率やアーキテクチャに大きく影響するもの [後回し] Lintでカバーできない細かいコーディングスタイルなど(新た な仕組みに乗った上で修正したい)
既存の機能の担保(守り)しながら 高速&安心なUI開発(攻め)に変えてゆく ※ 時間の都合上さくさくと
既存の機能の担保(守り) 大きめの改善施策を進めていく上でプロダクトの機能を守る施策 E2Eテスト刷新 Jestの導入 Datadogによる監視 Renovateによるパッケージ更新自動化
E2Eテスト刷新 課題; E2Eテストが壊れやすくメンテもされていなかった
E2Eテスト刷新 =>メンテされていないE2Eを保守しやすく刷新する with QA部
Jestの導入 課題; 多くのユニットテストがリクエスト単位での大きなテストで書か れている 課題; アーキテクチャとあわせてテスト設計されていない
Jestの導入 =>プログラムの適切な分解と、正しい責務のテストを効率的にに行う ための基盤として導入
Datadogによる監視 課題; ブラウザのエラーを拾えていない
Datadogによる監視 =>フロントエンドで起きた予期しないエラーを辿れるように
Renovateによるパッケージ更新自動化 課題; 依存モジュールの更新ができていない (メジャーバージョンだけで50以上)
Renovateによるパッケージ更新自動化 =>継続的にパッケージの更新を可能に =>更新されていないパッケージを可視化
既存の機能の担保(守り) =>最低限リファクタリングを進められる状態を整備
高速&安心なUI開発(攻め)
高速&安心なUI開発(攻め) より高速かつ安心してプロダクト開発を行うための施策 React, Next.js Emotion Storybook
課題 1. 画面とロジックが密結合していて開発効率が悪い 2. UIの変更や崩れが検知できていない 3. 使っているテンプレートエンジン( ect )がメンテされていない
Next.js, Emotion, Storybook
Why Next.js?
Why Next.js? =>我々だけのWhyがあるはず
アカウントサービスの前提 前提#1 アプリケーションは複雑 ビッグバンリリースを避け、段階的にリリースしたい 前提#2 フロントエンドが既存のExpressサーバーと密結合している箇所がある 既存のバックエンドのロジックをそのまま使いたい
アカウントサービスの前提 =>既存のExpressにのせながらアーキテクチャを変更できるか?が重 要
How Next.js? どうやる? Next.jsにも Subpath や Rewrites などルーティングベースで新旧のアプリケーション を切り替える機能がある =>アプリケーションは複雑で、すべてを書き換えるみちのりは長い
=>段階的にリリースできて、大きな初期コストがかからない方法がいい =>パスの切り替えはExpress側でもできるし、Next.jsの Custom Server を使えば IncrementalにNext.js化していくことが可能
How Next.js? =>Expressを Custom Server としてNext.jsを動かすことに
(アカウントサービスとしての) Why Next.js? パワフルな機能を柔軟なアーキテクチャで実装できる 既存のExpressアプリケーションをホストしつつReact化できる トランスパイラを抽象化でき、既存のビルドシステムの複雑さを吸収できる SSGが効果を発揮できそうなアプリケーション。将来的にNode.js環境をAPI化し、 JAMStack化しやすい コンポーネントとしてUI設計することで、将来的にポータブルにできる (Why
React) 様々なプラットフォーム・アプリケーションに対して 必要なUIを必要な分だけ 適切なAPIで提供したい
実際のリファクタ&開発フロー 触ったらリファクタするという強い意志で、ページごとNext.jsに乗せる 既存のReactコードがあった場合は適宜マイグレートしてSSR ビューに対するバックエンドロジックがあれば getServerSideProps へ & TS化 テストはUIからバックエンドまで、適切な粒度と責務でリバランス
高速&安心なUI開発(攻め) 1.フロントエンドだけで完結する高速な開発が可能に 2.再利用可能なUIコンポーネントを可視化 3.段階的にReact,Next.js化 4.段階的にEmotionでスタイルをスコープ化
新たな課題 共存することによるコスト チームで保守できる仕組み カナリアリリース、適切なモニタリング、負荷試験 デザインの一貫性(プラットフォーム全体でも) =>改善は継続的に続ける必要がある
None
どういう状態が理想か? =>事業部が簡単に導入できるような施策も進め、アジリティの高い組 織へ
おわり マイクロサービス化するバックエンド、レガシー化・モノリス化するフ ロントエンド =>そうならないために、適切な課題解決と技術選定、どんな形でも提 供できるポータブルなフロントエンドへ