实现的主要方法

• X. GraphQLエンドポイントでDevise認証も兼ねる

ドキュメントでいうMounting Operations In an Existing Schema

Y. APIとしてのGraphQLとDevise用のエンドポイントを分ける

DeviseにはREST APIのController経由でアクセス

Devise用のGraphQLエンドポイントを建てる方法もあるが、X,Y双方の悪いところを引き継ぐためあまりおすすめはしない

无论是哪一种情况，都要在前端保存成功认证时所需的认证令牌，并在将其发送到GraphQL时将认证令牌填入请求头中。如果服务器端请求头中包含正确的认证信息，则继续通信；否则，将返回错误。

通信路线可分为验证和API访问，并且最终在GraphQL端只需要查看被发送的API的验证令牌，因此两者都可以实现，但在一些细节上有一些区别。

• X. GraphQLエンドポイントでDevise認証も兼ねる

メリット

通信を全て一本のGraphQLでまかなえるのでシンプル

デメリット

一本化するに当たって専用のgem(graphql-devise)を使う必要があり、そんなに情報が転がっていない

特にあるライブラリとあるライブラリを掛け合わせて使うとき、その掛け合わせでの情報は更に探しにくいので問題の切り分けがかなり難しくなる

Y. APIとしてのGraphQLとDevise用のエンドポイントを分ける

メリット

ほぼ一般的なDeviseの利用法なので、情報がネットに溢れており、何かカスタマイズしたいときやエラーになったときに調べやすい

デメリット

1つのアプリの接続先が2本になる

フロントエンドから通信する先が2本になる
Rails側でGraphQLモジュールとControllerモジュールどちらも触ることになりあっちゃこっちゃする

GraphQLでの認証エラーでのハンドリングを自身で行う必要がある

在制作过程中参考的网站

如果是真的，我本来想展示存储库，或者进行详细的解释，但由于个人应用的存储库是私有的，并且解释会变得很冗长，所以我只上传了参考资料。如果有时间的话，我会去做的。

• X. GraphQLエンドポイントでDevise認証も兼ねる

graphql_deviseの公式ドキュメント
jwtを使ったGraphQL側との通信

Y. APIとしてのGraphQLとDevise用のエンドポイントを分ける

https://qiita.com/shu1124/items/e8c37b73e015afc63074

顺便说一下，虽然我是在“X. 实现GraphQL端点与Devise身份验证”的方面做的，但是遇到了很多困难，所以我会做些笔记备忘（如果有时间的话，我会详细写下来）。

• graphql-deviseで既存スキーマ上で認証を行ったとき

contextをController上でgql_devise_contextを使って作らないと、元々Controllerでガシガシ動くDeviseをうまく動かすことができない
上記に絡めて、テストをしようとしたらcontextからResource(例:User)を見つけられない、controllerを見つけられないというエラーに振り回されるので、Mutation単体でテスト、XXSchema.executeでテストしようとすると痛い目に合うので、大げさでもgraphqlエンドポイントにポスト通信とかでテストするのが吉

Apolloでレスポンスヘッダを見ようとすると、ログイン時のMutationのコールバックでいじれると思いきや、ApolloClientの通信全体のミドルウェアに挟む必要がある

https://zenn.dev/yosipy/articles/6bbd9c64b6ad74

Next.jsを使用していたため、サーバサイドでもCookieをいじる必要があり、nookiesライブラリを使うと捗った