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
740
DMMアカウントサービスのフロントエンド改善
okmttdhr
June 18, 2021
Tweet
Share
More Decks by okmttdhr
See All by okmttdhr
フロントエンドエコシステムで効率化する組織開発
okmttdhr
4
9.5k
スケーラブル CI/CD with Nx モノレポ
okmttdhr
5
2.3k
LambdaとDynamoDBでIoTバックエンド開発
okmttdhr
0
110
Other Decks in Programming
See All in Programming
Java 24まとめ / Java 24 summary
kishida
3
500
これだけは知っておきたいクラス設計の基礎知識 version 2
masuda220
PRO
24
6.4k
Chrome Extension Techniques from Hell
moznion
1
160
サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara
77web
4
670
Kamal 2 – Get Out of the Cloud
aleksandrov
1
190
Sharing features among Android applications: experience feedback
jbvincey
0
110
生成AIを使ったQAアプリケーションの作成 - ハンズオン補足資料
oracle4engineer
PRO
3
220
AI時代の開発者評価について
ayumuu
0
150
地域ITコミュニティの活性化とAWSに移行してみた話
yuukis
0
240
監視 やばい
syossan27
4
1.4k
Empowering Developers with HTML-Aware ERB Tooling @ RubyKaigi 2025, Matsuyama, Ehime
marcoroth
2
660
Optimizing JRuby 10
headius
0
320
Featured
See All Featured
Thoughts on Productivity
jonyablonski
69
4.6k
Designing Experiences People Love
moore
141
24k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
5
520
Mobile First: as difficult as doing things right
swwweet
223
9.6k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
A Modern Web Designer's Workflow
chriscoyier
693
190k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
41
2.2k
For a Future-Friendly Web
brad_frost
176
9.7k
Making Projects Easy
brettharned
116
6.1k
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
どういう状態が理想か? =>事業部が簡単に導入できるような施策も進め、アジリティの高い組 織へ
おわり マイクロサービス化するバックエンド、レガシー化・モノリス化するフ ロントエンド =>そうならないために、適切な課題解決と技術選定、どんな形でも提 供できるポータブルなフロントエンドへ