pixiv Inc.ピクシブ決済基盤のフロントエンドを改善していく話@yamasho
View Slide
Profileyamashoフロントエンドエンジニア● 2023/04 中途入社● フロントエンド歴5年● 最近ハマっているものはいろいろな味のサバ缶
今日話すこと● ピクシブ決済基盤とフロントエンドの課題について● どう解決するか○ 技術選定について○ 断続的なリプレイス戦略について● まとめ
今日話さないこと● 詳細な実装の内容● 各ライブラリや用語の説明(一部を除く)● いろいろな味のサバ缶について
ピクシブ決済基盤について
ピクシブ決済基盤について● カード一覧/選択/登録画面● 決済前確認画面● 銀行口座入力画面● etc…主な画面
カード登録画面
決済前確認画面
フロントエンドについて● Scala/Play Framework + テンプレートエンジン(twirl)● 基本VanillaJS(少しだけjQuery)● Storybook(htmlが2重管理されてる)● Tailwind CSSを使用した弊社デザインシステム● メンテナンスが滞っている
フロントエンド専任はyamashoのみ
ピクシブ決済基盤フロントエンドの改善できそうな課題
改善できそうな課題● テストが充実していない● 型安全でない(TypeScriptでない)● 命令的UIによる可読性● フロントエンドとバックエンドが密結合● 統一されたデザインに対してUIが再利用されていない● Storybookとテンプレートエンジンの親和性が低い
主に開発体験や堅牢性部分の不安→ 改修のハードル
どう解決していくか
コンポーネント化からモダンフロントエンドの領域を作り、改修のハードルを下げる
コンポーネント化からモダンフロントエンドの領域を作り、改修のハードルを下げるテスト型安全 再利用性宣言的UI
改善できそうな課題● テストが充実していない● 型安全でない(TypeScriptでない)● 命令的UIによる可読性● フロントエンドとバックエンドが密結合● 統一されたデザインに対してUIが再利用されていない● Storybookとテンプレートエンジンの親和性が低い脱テンプレートエンジンコンポーネント管理(TSX)
技術選定について
1. 脱テンプレートエンジン
バックエンドからのデータの受け渡し方法
アプリケーションは常にGrowthしていくもの
チーム状況的にリプレイスに注力は難しい時期もある
コストの軽いコンポーネント化に注力する
脱テンプレートエンジン→ 後回しでいいという選択
改善できそうな課題● テストが充実していない● 型安全でない(TypeScriptでない)● 命令的UIによる可読性● フロントエンドとバックエンドが密結合● 統一されたデザインに対してUIが再利用されていない● Storybookとテンプレートエンジンの親和性が低いテンプレートエンジン上でコンポーネント管理(TSX)
2. コンポーネントの管理
ピクシブ社内ではReactやNext.jsが人気
社内の知見が多いのはかなり魅力的
選ばれたのはPreactでした
Preactとは● とにかく軽量な仮想DOM系ライブラリ● Reactとほぼ同様のコードでコンポーネント作成が可能● Reactとエコシステムの互換性が高い(が、苦戦したという話もチラホラ…)→ 今回の用途はあくまでコンポーネント化
function Counter() {const [value, setValue] = useState(0);const increment = useCallback(() => {setValue(value + 1);}, [value]);return (Counter: {value}Increment);}
選ばれた理由● 目的を絞って最小限の機能で使う→ バンドルサイズを最小限に● Reactとほぼ同様のコード→ Preactで苦しみを感じた際、Reactへ移行しやすい● Web Components出力をサポート→ テンプレートエンジンに組み込みやすい
改善できそうな課題● テストが充実していない● 型安全でない(TypeScriptでない)● 命令的UIによる可読性● フロントエンドとバックエンドが密結合● 統一されたデザインに対してUIが再利用されていない● Storybookとテンプレートエンジンの親和性が低いテンプレートエンジン上でPreactを使ったコンポーネント管理(TSX)
断続的なリプレイス戦略
今までの経験
技術選定今まで経験したリプレイスリリース!リリースまでの流れアプリケーションのリプレイス新機能A新機能Aの取り込みレガシーリプレイスバグ修正バグ修正取り込み既存の凍結期間
苦しかった点● 一定期間大量にリソースを消費する● 現行システムとの同期を取ることに工数を使う○ 凍結期間でアプリケーションのGrowthが止まる● リリースまでの期間が長く伸びやすい○ 技術選定の事情も変化していく● 関わり方でリプレイスに対する意識の乖離が起きる
長期戦故の消耗
今回
環境構築リリースまでの流れ既存機能Aリプレイス新機能Aレガシーリプレイスバグ修正新機能AリプレイスVRT導入新機能B作成リリース リリース リリースリリース予定断続的リプレイスLP作ったり
昔: アプリケーションの技術刷新今: 機能ごとのコンポーネント化
小さい課題を短期間で片付けていくことが可能
アプリケーションのGrowthを止める事なく断続的に改善していく
まとめ● 課題を管理し、現在のチームの状態に合う選択を○ 今回の話: リソースを考慮し、目的を絞った上での負荷の少ない技術選定とリリース計画● 改善タスクに完璧な終わりはない→ 常に新陳代謝を繰り返す気持ち
Fluxライブラリは眼鏡のようなものです: あなたが必要な時にいつでも分かるのです。--Dan Abramov(Redux開発者)
ありがとうございました