GraphQLについて勉強したので、メモを殴り書き
こんにちは
最近GraphQLを使ってBFFを開発することになり、色々調べた結果を殴り書きしたいと思います。
あくまでも自分に向けたメモなので、大変見づらいと思います。そのうち整備するかも??
初めに
今回私はGoのgqlgenというライブラリを用いて開発をする予定です。 gqlgenを採用した意図はいくつかありますが、特徴としてスキーマベースということがあります。
開発に入る前に、スキーマを定義し開発メンバーで叩き上げることで仕様の確定/確認を進めつつ、認識の相違を洗い出すことができると考えています。
本記事はその過程でGraphQLの仕様やスキーマのベストプラクティスについて調べた結果です。
調べたこと
https://productionreadygraphql.com/2020-08-01-guide-to-graphql-errors API内のログとしてエラーを表示することは問題ないが、クライアントへ送信するエラーはエラーコードで抽象化する デメリット メリット
- エラーに関する一貫性が生まれる
- ステージ2では、アドホックなエラースキーマを定義することでフロントの負担もあったが、この場合は必要としない デメリット
- エラーフィールドを選択しないことで、クライアントがエラーを完全に無視するのが非常に簡単なことGraphQLエラーのガイド
読んだサイト
自分なりの理解
ステージ1
ユーザーのデータをエラーとして表すことはできない。
→ステータスコードだけでなく、エラーコードの意味を決めて用いることによって、一貫性を保つことができる
トップレベルのエラーに出すべきなのは、DBが使えない!なども致命的なもののみで良いステージ2
type Mutation {
createUser(input: CreateUserInput!): CreateUserPayload
}
# 💡The "MutationPayload" wrapper type is a common convention
# initially specified by the GraphQL client Relay
type CreateUserPayload {
user: User
userNameWasTaken: Boolean!
userNameAlternative: String!
}
この例では、エラーの処理に役立つ2つのフィールドをミューテーションペイロードタイプに追加しました。createUser誰かが作成したいユーザー名がすでに存在する場合、はエラーになる可能性があります。この場合、エラーを表示し、入力内容に基づいてより適切なユーザー名を提案します。
- エラー時の内容によったクライアントの追加機能実装が必要になり困難かもしれない
- エラースキーマが増えるので、別途説明を記載したドキュメントを作成する必要が出てくる
- エラーのスキーマに一貫性がなくなっていくので、人間のエラー発見難易度が高くなる可能性があるステージ3
→注釈を追記する(選択必須など)ステージ4
エラーの共通インターフェースがあることで、クライアントはエラー間の共通の契約を知っているだけでなく、必要に応じて新しい、より具体的なエラータイプを作成することが可能ステージ5以降は割と直感的に理解ができたため、メモしていない
GraphQLスキーマ設計のためのベストプラクティス
https://kaminashi-developer.hatenablog.jp/entry/2020/12/11/093000 調査の結果今回自分が開発するものには必要ないかな(部分的には使える)と思いました。GoでGraphQL Subscriptionsを実装する
読んだサイト
メモ
ページングについて
後書き
まだまだデータローダー、ページングなど勉強しないとならない部分しか見つかりません🥺
どんどん追記して行きたいと思います。