テーブルが200以上あるSaaSでRSCとGraphQLを併用する理由

テーブルが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 を適材適所に活用し、併用することで快適な開発環境を実現できている

テーブルが200以上あるSaaSでRSCとGraphQLを併用する理由

テーブルが200以上あるSaaSでRSCとGraphQLを併用する理由

msickpaler

Other Decks in Technology

Featured

Transcript