https://techblog.gaudiy.com/entry/2021/10/20/121501

こんにちは！Gaudiyのエンジニアの永井（@sho0910K）です。

Gaudiyでは昨年からGraphQLを導入し、スキーマ駆動開発に取り組んできました。導入からまもなく1年を迎えようとしていますが、良かったところや、改めて浮き彫りになった課題や気づきがあったので、今回はGraphQLの取り組みについてまとめてみたいと思います。

GraphQLの導入を検討しているチームや、実際に活用しているチームのご参考になれば嬉しいです。

• 1. GraphQL導入の背景
• 2. GraphQLをプロダクトでどのように活用しているのか

導入の背景については「技術スタックと選定における思想」というブログでも簡単に触れましたが、もともとGaudiyでは、フロントエンドとバックエンドでAPIインターフェイスの認識齟齬が発生することから手戻りが起こり、開発効率を下げているという課題がありました。

またフロントエンドでは、事業ドメインの複雑化によって展開するコミュニティごとに提供する機能や扱うデータが異なったり、扱うデータの増加によってアプリケーションとして管理するデータが複雑化したり、といった状況でした。

具体的には、GraphQL導入以前は、状態管理をRedux、データベースとしてFirestoreを利用していましたが、バックエンドのマイクロサービス群と掛け合わせたクライアントサイドジョインも多くなり、クライアントからのリクエスト数の増加や扱うグローバルステートが増えたことで、コードが複雑化して可読性も低くなっていました。

結果として、状態管理やコンポーネントの繋がりが見えにくくなり、意図しないところで再レンダリングが発生するなど、プロダクトのユーザー体験として思わしくない課題を抱えていました。

Gaudiyが提供しているコミュニティアプリは、コミュニティごとに提供する機能や扱うデータに差があります。

この理由としては、Gaudiyが提供するコミュニティの主軸はIPコンテンツになりますが、IPごとにファンのユーザー層も様々です。そのため、提供する機能の出し方に関しても、そのファン層が利用しやすい形態として提供するなど、IPごとの考慮も必要になってきます。

この差分をBFF（backend for frontend）であるGraphQLサーバーを使って、できるだけ複雑性を回避したフロントエンドで扱いやすいデータとして返却しています。

例えば、コミュニティ内でNFTアイテムを提供するサービスに関しても、コミュニティ内のストアを通して手に入れられるものや、イベントに参加することで手に入れられるものなど、獲得方法はコミュニティによって様々です。この差異をBFFであるGraphQLサーバーにてマージ処理を挟むことで、できるだけフロントエンドでロジックを挟まずにデータ展開できるようにしています。

Gaudiyのバックエンドは、各コミュニティで必要な機能をマイクロサービスとして構成しており、各サービスのレスポンスをコミュニティのユーザーデータと組み合わせて返却しています。機能単位にマイクロサービス化している意図としては、作成時は特定のコミュニティに対して特化した機能だったとしても、ユーザー体験の改善や機能拡張をしながら他のコミュニティでも展開できるようにするためです。こうすることで、サービス単体として継続的な機能開発やデプロイを実行しやすくしています。

これらのマイクロサービスで構成された機能群を、BFFであるGraphQLサーバーを通すことで複雑性を回避し、フロントエンドではできるだけユーザー体験の最適化にフォーカスできるようにしています。