テーブルが200 以上あるSaaS で RSC とGraphQL を併用する理由 by ficilcom 株式会社 msickpaler

自己紹介 現在のポジション ficilcom 株式会社 フロントエンドエンジニア 経歴 フロントエンドエンジニア歴4 年 App Router をstable release から使っている TypeScript の記事多め 個人開発はRemix

アジェンダ 1. プロダクト紹介 NeX-Ray 2. RSC とGraphQL のおさらい 3. RSC とGraphQL の併用理由 4. まとめ

NeX-Ray とは あらゆるWeb データをひとつに いろんなメディア情報を一元管理 マーケティングミックスモデリング SaaS での価格モデル ワンクリックでレポート可視化 戦略的なマーケティングを支援

NeX-Ray で頻出する画面

アーキテクチャ

フロントエンドのテックスタック フレームワーク: Next.js(App Router) データフェッチ: GraphQL, Apollo Client RSC とGraphQL を併用している

前提知識

RSC とは？ サーバーで実行されるreact コンポーネント 主な特徴 サーバー側で動作するので同じネットワークやデータセンターでは高速通信できる 一度しかレンダリングされないのでパフォーマンスが良い GraphQL とは？ クエリ言語の一種で、必要なデータを1 回のリクエストで取得できる 主な特徴 一度で必要なデータを取得できる 一度GraphQL のスキーマを作ってしまえば、API の変更無しでフロントエンド側で取得するデータを選べる

NeX-Ray の例を紹介していく

NeX-Ray の技術的課題 初期リリース時にテーブル数200 超え（今後も増え続ける） メンテが大変 BtoB SaaS なので会社ごとのセキュリティ担保や権限管理が必要 テナント分離 権限管理 膨大なテーブルのカラム数 MAX 300 カラム超えのテーブルもある

GraphQL の採用理由 スタートアップで200 テーブルを素直に扱うのはメンテコストが高すぎる BtoB SaaS ではテナント分離が重要なのでRLS が必須 カラムの取捨選択をしないと300 カラムすべてを取得することになる RLS(Row-Level Security) を利用しながらDB スキーマから自動的にGraphQL のAPI を生成できるPostGraphile は 唯一無二の選択肢だった つまりGraphQL の利用はサーバーサイド都合で不可欠だった。 よって、GraphQL 採用は確定

PostGraphile の例 const app = express(); app.use(postgraphile(DATABASE_URL, schemaName)); app.listen(4000);

PostGraphile のデメリット 自動生成故に間にロジックを差し込みにくい NeX-Ray の場合だと、権限やサブスクリプション情報などで条件分岐する場合に実装が面倒くさい

RSC の採用理由 NeX-Ray での活用方法 権限管理ロジック 連携している媒体のアカウントごとのview / edit / admin 権限の制御 組織のグループやユーザーごとのview / edit / admin 権限の制御 サブスクリプションごとの権限の制御 メトリクスの計算ロジック 期間ごとに見たいデータを表示する クリック率, コンバージョン率, インプレッション単価, 成約単価, クリック単価, 予算達成率 …etc. 権限管理をRSC で実行することでPostGraphile のデメリットを補っている

まとめ: RSC とGraphQL の併用した結果 GraphQL(PostGraphile) RLS によるテナント管理のセキュリティ担保 自動生成されたAPI エンドポイント 広告モデルとの相性の良さ RSC 権限管理をサーバーサイドで行うことでセキュリティ向上 計算をサーバーサイドで行うことでパフォーマンス向上 Nex-Ray では、GraphQL とRSC を適材適所に活用し、併用することで快適な開発 環境を実現できている