$30 off During Our Annual Pro Sale. View Details »

DMMアカウントサービスのフロントエンド改善

 DMMアカウントサービスのフロントエンド改善

okmttdhr

June 18, 2021
Tweet

More Decks by okmttdhr

Other Decks in Programming

Transcript

  1. DMMアカウントサービスのフロントエンド改善

    View Slide

  2. 自己紹介
    2020年10月入社
    DMMプラットフォーム事業本部エンジニア
    相席食堂にハマっている

    View Slide

  3. テーマ: DMMアカウントサービスのフロントエンド改善
    半年ほど前からフロントエンドに対する技術的な改善プロジェクトがスタート
    どのような課題・理想があり、それに対してどう技術的なアプローチをしているのかを
    話します

    View Slide

  4. アジェンダ
    アカウントサービスの理想
    アカウントサービスの課題
    既存の機能の担保する(守り)
    高速&安心なUI開発に変えてゆく(攻め)

    View Slide

  5. プラットフォーム事業本部とは
    DMMの中でも横断的な機能を提供する部署
    トップページ、認証、決済、ヘッダー、フッター、etc
    アカウントサービスは認証認可を担当するアプリケーション
    いわゆるログイン・登録機能

    View Slide

  6. プラットフォーム事業本部とは
    =>チームに閉じた効率化はもちろんだが、各事業部が簡単に機能を使
    えるようにすることで、組織全体の効率化につながるのが特徴

    View Slide

  7. どういう状態が理想か?
    アカウントサービスのやりたいことはたくさん
    様々なアプリケーション: DMMには50以上の事業がある。DMMログインを使いたい
    が、「デザインはサービスに合うように変えて欲しい」のような要望がある
    様々なプラットフォーム: SPAで使いたい、PWAで使いたい、Electronで使いたい、TV
    で使いたい、PS5で使いたい、アプリで使いたい、独自ログインを提供したい、、
    様々なユースケース: SNSログインしたい、他社からDMMアカウントでOIDCしたい、多
    要素認証を実装してほしい
    =>これらに素早く対応できる、拡張性・ポータビリティの高いソフト
    ウェアにしておきたい

    View Slide

  8. どういう状態が理想か?
    ソフトウェアとして
    変更がしやすい
    テスタビリティが高い
    ビジネスとして
    事業部に簡単に提供できる
    施策の素早い検証と改善が行える

    View Slide

  9. どういう状態が理想か?
    =>変更容易性が高く、素早く安心してアプリケーションをデプロイで
    きる状態

    View Slide

  10. 既存の技術スタック
    Node.js+Expressのサーバーサイドアプリケーション
    もともと巨大なPHPモノリスから
    切り出されて再実装された
    基本はテンプレートエンジン。要所でReactを使用(webpack)
    Node.jsバックエンドをBFFとし、認証認可・会員・社内基盤等のサービス、APIとやり
    取り(Javaが多い)
    上記の事情から、Node.jsのバックエンドに多くのビジネスロジック
    ECS上で動く。要所でLambdaやRedisを使用

    View Slide

  11. 既存の技術スタック
    =>Node.js+Express
    =>フロントエンドの持ち物 = いわゆるフロントエンド+BFF

    View Slide

  12. 既存アプリケーションの技術的な課題を洗い出し

    依存モジュールの更新ができていない(メジャーバージョンだけで50以上)
    使用しているテンプレートエンジン( ect
    )がメンテされていない
    CSSがスコープ化されておらず、また、影響範囲の大きな書き方がされている
    多くのユニットテストがリクエスト単位での大きなテストで書かれており、アーキテク
    チャとあわせてテスト設計されていない
    UIとロジックが密結合していて開発しづらく、テストもされていない
    E2Eテストが壊れやすくメンテもされていない
    ブラウザのエラーを拾えていない
    (歴史的経緯により)多くの独自 node_modules
    全体的に古い書き方のコード( cjs
    , Class Component
    , jQuery
    etc)

    View Slide

  13. 既存アプリケーションの技術的な課題を洗い出し
    =>それぞれの課題同士に依存関係がありそう

    View Slide

  14. 既存アプリケーションの技術的な課題の優先度付け

    View Slide

  15. 既存アプリケーションの技術的な課題の優先度付け
    課題を洗い出し、優先度をつけて取り組むことに。
    例えば、
    [優先] 以降の開発効率やアーキテクチャに大きく影響するもの
    [後回し] Lintでカバーできない細かいコーディングスタイルなど(新た
    な仕組みに乗った上で修正したい)

    View Slide

  16. 既存の機能の担保(守り)しながら
    高速&安心なUI開発(攻め)に変えてゆく

    時間の都合上さくさくと

    View Slide

  17. 既存の機能の担保(守り)
    大きめの改善施策を進めていく上でプロダクトの機能を守る施策
    E2Eテスト刷新
    Jestの導入
    Datadogによる監視
    Renovateによるパッケージ更新自動化

    View Slide

  18. E2Eテスト刷新
    課題; E2Eテストが壊れやすくメンテもされていなかった

    View Slide

  19. E2Eテスト刷新
    =>メンテされていないE2Eを保守しやすく刷新する with QA部

    View Slide

  20. Jestの導入
    課題; 多くのユニットテストがリクエスト単位での大きなテストで書か
    れている
    課題; アーキテクチャとあわせてテスト設計されていない

    View Slide

  21. Jestの導入
    =>プログラムの適切な分解と、正しい責務のテストを効率的にに行う
    ための基盤として導入

    View Slide

  22. Datadogによる監視
    課題; ブラウザのエラーを拾えていない

    View Slide

  23. Datadogによる監視
    =>フロントエンドで起きた予期しないエラーを辿れるように

    View Slide

  24. Renovateによるパッケージ更新自動化
    課題; 依存モジュールの更新ができていない
    (メジャーバージョンだけで50以上)

    View Slide

  25. Renovateによるパッケージ更新自動化
    =>継続的にパッケージの更新を可能に
    =>更新されていないパッケージを可視化

    View Slide

  26. 既存の機能の担保(守り)
    =>最低限リファクタリングを進められる状態を整備

    View Slide

  27. 高速&安心なUI開発(攻め)

    View Slide

  28. 高速&安心なUI開発(攻め)
    より高速かつ安心してプロダクト開発を行うための施策
    React, Next.js
    Emotion
    Storybook

    View Slide

  29. 課題
    1. 画面とロジックが密結合していて開発効率が悪い
    2. UIの変更や崩れが検知できていない
    3. 使っているテンプレートエンジン( ect
    )がメンテされていない

    View Slide

  30. Next.js, Emotion, Storybook

    View Slide

  31. Why Next.js?

    View Slide

  32. Why Next.js?
    =>我々だけのWhyがあるはず

    View Slide

  33. アカウントサービスの前提
    前提#1
    アプリケーションは複雑
    ビッグバンリリースを避け、段階的にリリースしたい
    前提#2
    フロントエンドが既存のExpressサーバーと密結合している箇所がある
    既存のバックエンドのロジックをそのまま使いたい

    View Slide

  34. アカウントサービスの前提
    =>既存のExpressにのせながらアーキテクチャを変更できるか?が重

    View Slide

  35. How Next.js?
    どうやる?
    Next.jsにも Subpath
    や Rewrites
    などルーティングベースで新旧のアプリケーション
    を切り替える機能がある
    =>アプリケーションは複雑で、すべてを書き換えるみちのりは長い
    =>段階的にリリースできて、大きな初期コストがかからない方法がいい
    =>パスの切り替えはExpress側でもできるし、Next.jsの Custom Server
    を使えば
    IncrementalにNext.js化していくことが可能

    View Slide

  36. How Next.js?
    =>Expressを Custom Server
    としてNext.jsを動かすことに

    View Slide

  37. (アカウントサービスとしての) Why Next.js?
    パワフルな機能を柔軟なアーキテクチャで実装できる
    既存のExpressアプリケーションをホストしつつReact化できる
    トランスパイラを抽象化でき、既存のビルドシステムの複雑さを吸収できる
    SSGが効果を発揮できそうなアプリケーション。将来的にNode.js環境をAPI化し、
    JAMStack化しやすい
    コンポーネントとしてUI設計することで、将来的にポータブルにできる
    (Why React)
    様々なプラットフォーム・アプリケーションに対して
    必要なUIを必要な分だけ
    適切なAPIで提供したい

    View Slide

  38. 実際のリファクタ&開発フロー
    触ったらリファクタするという強い意志で、ページごとNext.jsに乗せる
    既存のReactコードがあった場合は適宜マイグレートしてSSR
    ビューに対するバックエンドロジックがあれば getServerSideProps
    へ & TS化
    テストはUIからバックエンドまで、適切な粒度と責務でリバランス

    View Slide

  39. 高速&安心なUI開発(攻め)
    1.フロントエンドだけで完結する高速な開発が可能に
    2.再利用可能なUIコンポーネントを可視化
    3.段階的にReact,Next.js化
    4.段階的にEmotionでスタイルをスコープ化

    View Slide

  40. 新たな課題
    共存することによるコスト
    チームで保守できる仕組み
    カナリアリリース、適切なモニタリング、負荷試験
    デザインの一貫性(プラットフォーム全体でも)
    =>改善は継続的に続ける必要がある

    View Slide

  41. View Slide

  42. どういう状態が理想か?
    =>事業部が簡単に導入できるような施策も進め、アジリティの高い組
    織へ

    View Slide

  43. おわり
    マイクロサービス化するバックエンド、レガシー化・モノリス化するフ
    ロントエンド
    =>そうならないために、適切な課題解決と技術選定、どんな形でも提
    供できるポータブルなフロントエンドへ

    View Slide