「プレイド/LayerX/ナレッジワーク_Webフロントエンドを軸に、幅を広げたエンジニアたちの仕事」に参加してきました

• 2024/11/6
• https://plaidtech.connpass.com/event/328629/

コンポーネントのダイバーシティ?

• kazuponさん（プレイド）

ライブラリが混在したコンポーネント

• React,Vueなど異なるライブラリのコンポーネントを混在させたい
• 混在させるためには
  • WebComponents化
    • ライブラリで出力するとかだとそれぞれのランタイム必要だったり
    • SSR対応
  • IFrameで
    • postMessageでやりとりすることになる
    • それぞれで読み込むしパフォーマンスが
  • Astroとかでアイランドアーキテクチャ
    • 多用なライブラリを読み込めるのはastroコンポーネントだけ
    • astroファイルのメンテ

npmパッケージじゃない仕組みで共有ライブラリを管理する

• yuheiさん（プレイド）

パッケージ管理

• 大量の定数を管理するパッケージ
  • いろんなアプリから利用される
  • バージョンアップしても利用者があげてくれない問題
  • 以前はリリース時に利用側もアップデートしていた
• 定数ファイルをコピーして配布する仕組みを作った
  • 依存箇所をファイルで管理してそこにコピーして配布する

コンパウンド戦略を支えるフロントエンド基盤設計

• よしこさん（ナレッジワーク）

アプリの分割

• 今までは1つのアプリケーションに全部入ってた
  • それを分割しようとしてる
  • 垂直分割マイクロフロントエンド
• 複数のプロダクトをスピード感を持って進めたい
  • 依存があるとダメ
  • 共通で使えるものは使い回したい
• pnpm workspace
• Turborepo
  • build順のコントロール
• 共通のGlobalStateはLocalStorageで管理

コンパウンド戦略を支えるデザインシステムの力：一貫性とスケールの実現

• fishさん（ナレッジワーク）

デザインシステム

• デザインルールが実装に適用されてない
• デザインと開発の不一致

WebフロントエンドにおけるGraphQL（あるいはバックエンドのAPI）との向き合い方

• izuminさん（LayerX）
• https://speakerdeck.com/izumin5210/number-241106-plk-frontend

API

• APIが多様
  • どんな技術使うか
  • スキーマ設計どうするか
  • BFF置くかとか

複雑化したcomponent群と向き合う

• deltaさん（LayerX）

コンポーネントの複雑化

• ドメインが複雑
• ライブラリ/アーキテクチャの変化
  • atomic designとの相性の悪さ
    • 仕様上共通度が小さく何をやってるかわからないコンポーネントができていく
  • Vue2からVue3移行するのに型付けの難しさ
• 地道な改善
  • 機能単位のディレクトリを作って新規はそこに
  • 型エラーの対応