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

by yamashooooo

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

カード登録画面

Slide 8

Slide 8 text

決済前確認画面

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

どう解決していくか

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

技術選定について

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

選ばれたのは Preactでした

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Counter: {value} Increment

); }

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

断続的なリプレイス戦略

Slide 38

Slide 38 text

今までの経験

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

長期戦故の消耗

Slide 42

Slide 42 text

今回

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

ありがとうございました