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

【PIXIV MEETUP 2023】ピクシブ決済基盤のフロントエンドを改善していく話

yamashooooo
September 29, 2023
460

【PIXIV MEETUP 2023】ピクシブ決済基盤のフロントエンドを改善していく話

yamashooooo

September 29, 2023
Tweet

Transcript

  1. pixiv Inc.
    ピクシブ決済基盤の
    フロントエンドを
    改善していく話
    @yamasho

    View Slide

  2. Profile
    yamasho
    フロントエンドエンジニア
    ● 2023/04 中途入社
    ● フロントエンド歴5年
    ● 最近ハマっているものは
    いろいろな味のサバ缶

    View Slide

  3. 今日話すこと
    ● ピクシブ決済基盤とフロントエンドの課題について
    ● どう解決するか
    ○ 技術選定について
    ○ 断続的なリプレイス戦略について
    ● まとめ

    View Slide

  4. 今日話さないこと
    ● 詳細な実装の内容
    ● 各ライブラリや用語の説明(一部を除く)
    ● いろいろな味のサバ缶について

    View Slide

  5. ピクシブ決済基盤
    について

    View Slide

  6. ピクシブ決済基盤について
    ● カード一覧/選択/登録画面
    ● 決済前確認画面
    ● 銀行口座入力画面
    ● etc…
    主な画面

    View Slide

  7. カード登録画面

    View Slide

  8. 決済前確認画面

    View Slide

  9. フロントエンドについて
    ● Scala/Play Framework + テンプレートエンジン
    (twirl)
    ● 基本VanillaJS(少しだけjQuery)
    ● Storybook(htmlが2重管理されてる)
    ● Tailwind CSSを使用した弊社デザインシステム
    ● メンテナンスが滞っている

    View Slide

  10. フロントエンド専任は
    yamashoのみ

    View Slide

  11. ピクシブ決済基盤
    フロントエンドの
    改善できそうな課題

    View Slide

  12. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い

    View Slide

  13. 主に開発体験や
    堅牢性部分の不安
    → 改修のハードル

    View Slide

  14. どう解決していくか

    View Slide

  15. コンポーネント化から
    モダンフロントエンドの
    領域を作り、
    改修のハードルを下げる

    View Slide

  16. コンポーネント化から
    モダンフロントエンドの
    領域を作り、
    改修のハードルを下げる
    テスト
    型安全 再利用性
    宣言的UI

    View Slide

  17. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い

    View Slide

  18. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    脱テンプレートエンジン
    コンポーネント管理(TSX)

    View Slide

  19. 技術選定について

    View Slide

  20. 1. 脱テンプレートエンジン

    View Slide

  21. バックエンドからの
    データの受け渡し方法

    View Slide

  22. アプリケーションは常に
    Growthしていくもの

    View Slide

  23. チーム状況的に
    リプレイスに注力は
    難しい時期もある

    View Slide

  24. コストの軽い
    コンポーネント化に
    注力する

    View Slide

  25. 脱テンプレートエンジン
    → 後回しでいいという選択

    View Slide

  26. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    脱テンプレートエンジン
    コンポーネント管理(TSX)

    View Slide

  27. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    テンプレートエンジン上で
    コンポーネント管理(TSX)

    View Slide

  28. 2. コンポーネントの管理

    View Slide

  29. ピクシブ社内では
    ReactやNext.jsが人気

    View Slide

  30. 社内の知見が多いのは
    かなり魅力的

    View Slide

  31. 選ばれたのは
    Preactでした

    View Slide

  32. Preactとは
    ● とにかく軽量な仮想DOM系ライブラリ
    ● Reactとほぼ同様のコードでコンポーネント作成が可能
    ● Reactとエコシステムの互換性が高い
    (が、苦戦したという話もチラホラ…)
    → 今回の用途はあくまでコンポーネント化

    View Slide

  33. function Counter() {
    const [value, setValue] = useState(0);
    const increment = useCallback(() => {
    setValue(value + 1);
    }, [value]);
    return (

    Counter: {value}
    Increment

    );
    }

    View Slide

  34. 選ばれた理由
    ● 目的を絞って最小限の機能で使う
    → バンドルサイズを最小限に
    ● Reactとほぼ同様のコード
    → Preactで苦しみを感じた際、Reactへ移行しやすい
    ● Web Components出力をサポート
    → テンプレートエンジンに組み込みやすい

    View Slide

  35. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    テンプレートエンジン上で
    コンポーネント管理(TSX)

    View Slide

  36. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない(TypeScriptでない)
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    テンプレートエンジン上で
    Preactを使った
    コンポーネント管理(TSX)

    View Slide

  37. 断続的なリプレイス戦略

    View Slide

  38. 今までの経験

    View Slide

  39. 技術選定
    今まで経験したリプレイス
    リリース!
    リリースまでの流れ
    アプリケーションのリプレイス
    新機能A
    新機能Aの取り込み
    レガシー
    リプレイス
    バグ修正
    バグ修正
    取り込み
    既存の凍結期間

    View Slide

  40. 苦しかった点
    ● 一定期間大量にリソースを消費する
    ● 現行システムとの同期を取ることに工数を使う
    ○ 凍結期間でアプリケーションのGrowthが止まる
    ● リリースまでの期間が長く伸びやすい
    ○ 技術選定の事情も変化していく
    ● 関わり方でリプレイスに対する意識の乖離が起きる

    View Slide

  41. 長期戦故の消耗

    View Slide

  42. 今回

    View Slide

  43. 環境構築
    リリースまでの流れ
    既存機能A
    リプレイス
    新機能A
    レガシー
    リプレイス
    バグ修正
    新機能A
    リプレイス
    VRT
    導入
    新機能B
    作成
    リリース リリース リリース
    リリース
    予定
    断続的リプレイス
    LP作ったり

    View Slide

  44. 昔: アプリケーションの技術刷新
    今: 機能ごとのコンポーネント化

    View Slide

  45. 小さい課題を短期間で
    片付けていくことが可能

    View Slide

  46. アプリケーションの
    Growthを止める事なく
    断続的に改善していく

    View Slide

  47. まとめ
    ● 課題を管理し、現在のチームの状態に合う選択を
    ○ 今回の話: リソースを考慮し、目的を絞った上での
    負荷の少ない技術選定とリリース計画
    ● 改善タスクに完璧な終わりはない
    → 常に新陳代謝を繰り返す気持ち

    View Slide

  48. Fluxライブラリは眼鏡のようなものです: あなたが必
    要な時にいつでも分かるのです。
    --Dan Abramov(Redux開発者)

    View Slide

  49. ありがとうございました

    View Slide