主な実現方法
- X. GraphQLエンドポイントでDevise認証も兼ねる
- Y. APIとしてのGraphQLとDevise用のエンドポイントを分ける
- DeviseにはREST APIのController経由でアクセス
- Devise用のGraphQLエンドポイントを建てる方法もあるが、X,Y双方の悪いところを引き継ぐためあまりおすすめはしない
- DeviseにはREST APIのController経由でアクセス
どちらも、認証成功時の認証用トークンをフロントエンドに保持し、
GraphQLに投げるときにはリクエストヘッダに認証用トークンを詰めて、
サーバサイドでリクエストヘッダに正規の認証情報があれば通信を継続して、なければエラーにするというロジック
通信経路としては認証とAPIアクセスは分断可能であり、結局GraphQL側ではAPIを投げられたときの認証トークンを見ればいいだけなので、どちらでも実装可能だが、
細かいところでそれぞれ違いがある
- X. GraphQLエンドポイントでDevise認証も兼ねる
- メリット
- 通信を全て一本のGraphQLでまかなえるのでシンプル
- デメリット
- 一本化するに当たって専用のgem(graphql-devise)を使う必要があり、そんなに情報が転がっていない
- 特にあるライブラリとあるライブラリを掛け合わせて使うとき、その掛け合わせでの情報は更に探しにくいので問題の切り分けがかなり難しくなる
- 一本化するに当たって専用のgem(graphql-devise)を使う必要があり、そんなに情報が転がっていない
- メリット
- Y. APIとしてのGraphQLとDevise用のエンドポイントを分ける
- メリット
- ほぼ一般的なDeviseの利用法なので、情報がネットに溢れており、何かカスタマイズしたいときやエラーになったときに調べやすい
- デメリット
- 1つのアプリの接続先が2本になる
- フロントエンドから通信する先が2本になる
- Rails側でGraphQLモジュールとControllerモジュールどちらも触ることになりあっちゃこっちゃする
- GraphQLでの認証エラーでのハンドリングを自身で行う必要がある
- 1つのアプリの接続先が2本になる
- メリット
作成時に参考にしたサイト
本当であればリポジトリを見せたり、細かく説明するとかしたりしたいんですが、
個人アプリでリポジトリがプライベートなのと、説明が結構長くなってしまうので参考資料を載せるだけにしました。
時間あったらやります
- X. GraphQLエンドポイントでDevise認証も兼ねる
- Y. APIとしてのGraphQLとDevise用のエンドポイントを分ける
ちなみに私は「X. GraphQLエンドポイントでDevise認証も兼ねる」側でやったんですが、詰まったところが多かったので、メモしておきます（時間できたら詳しく書きます）
- graphql-deviseで既存スキーマ上で認証を行ったとき
- contextをController上でgql_devise_contextを使って作らないと、元々Controllerでガシガシ動くDeviseをうまく動かすことができない
- 上記に絡めて、テストをしようとしたらcontextからResource(例:User)を見つけられない、controllerを見つけられないというエラーに振り回されるので、Mutation単体でテスト、
XXSchema.executeでテストしようとすると痛い目に合うので、大げさでもgraphqlエンドポイントにポスト通信とかでテストするのが吉
- Apolloでレスポンスヘッダを見ようとすると、ログイン時のMutationのコールバックでいじれると思いきや、ApolloClientの通信全体のミドルウェアに挟む必要がある
- Next.jsを使用していたため、サーバサイドでもCookieをいじる必要があり、nookiesライブラリを使うと捗った