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
770
DMMアカウントサービスのフロントエンド改善
okmttdhr
June 18, 2021
Tweet
Share
More Decks by okmttdhr
See All by okmttdhr
フロントエンドエコシステムで効率化する組織開発
okmttdhr
4
9.7k
スケーラブル CI/CD with Nx モノレポ
okmttdhr
5
2.3k
LambdaとDynamoDBでIoTバックエンド開発
okmttdhr
0
140
Other Decks in Programming
See All in Programming
Reduxモダナイズ 〜コードのモダン化を通して、将来のライブラリ移行に備える〜
pvcresin
2
680
詳しくない分野でのVibe Codingで困ったことと学び/vibe-coding-in-unfamiliar-area
shibayu36
3
4.2k
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1k
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
160
Чего вы не знали о строках в Python – Василий Рябов, PythoNN
sobolevn
0
150
非同期jobをtransaction内で 呼ぶなよ!絶対に呼ぶなよ!
alstrocrack
0
500
ABEMAモバイルアプリが Kotlin Multiplatformと歩んだ5年 ─ 導入と運用、成功と課題 / iOSDC 2025
akkyie
0
320
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
330
Model Pollution
hschwentner
1
180
クラシルを支える技術と組織
rakutek
0
190
Serena MCPのすすめ
wadakatu
4
880
育てるアーキテクチャ:戦い抜くPythonマイクロサービスの設計と進化戦略
fujidomoe
1
150
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Designing Experiences People Love
moore
142
24k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Statistics for Hackers
jakevdp
799
220k
A Modern Web Designer's Workflow
chriscoyier
697
190k
The Power of CSS Pseudo Elements
geoffreycrofte
79
6k
RailsConf 2023
tenderlove
30
1.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
890
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
960
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
どういう状態が理想か? =>事業部が簡単に導入できるような施策も進め、アジリティの高い組 織へ
おわり マイクロサービス化するバックエンド、レガシー化・モノリス化するフ ロントエンド =>そうならないために、適切な課題解決と技術選定、どんな形でも提 供できるポータブルなフロントエンドへ