web-dev-qa-db-ja.com

GraphQLIntの代わりにGraphQLIDを使用する場合

GraphQLID の代わりに GraphQLInt を使用するタイミングは明確ではありません。

次のスキーマを検討してください。

type User {
  id: Int!
  firstName: String!
  lastName: String!
}

type Query {
  user (id: ID!): User
}

の場合には Query.user、GraphQLIDを使用するかGraphQLIntを使用するかに違いはないようです。

の場合には User.id、GraphQLIDを使用すると、入力が文字列にキャストされます。 GraphQLIntを使用すると、入力が確実に整数になります。

これにより、クエリと型システムの一貫性が失われます。

graphql-jsspec は、単に言う：

IDを表すGraphQLScalarType。

これは実装の詳細ですか（たとえば、GraphQLクライアントはGraphQLIDを整数にキャストできる場合）、またはIDは常に graphql の文字列であると予想されますか？

graphqlgraphql-js
31
Gajus

GraphQLの仕様を見ました。

IDスカラー型は一意の識別子を表し、多くの場合、オブジェクトの再取得やキャッシュのキーとして使用されます。 IDタイプは、Stringと同じ方法でシリアル化されます。ただし、人間が読めるようには意図されていません。多くの場合数値ですが、常にStringとしてシリアル化する必要があります。

– https://facebook.github.io/graphql/April2016/#sec-ID

これは、実装に委ねるか仕様で指示するか、つまりIDは常にStringにシリアル化する必要があるかどうかという質問に答えます。

さらに、入力タイプのコンテキストでは、入力を文字列に強制する必要があります。仕様から：

入力強制

入力タイプとして期待される場合、任意の文字列（"4"など）または整数（4など）の入力値は、指定されたGraphQLサーバーが期待するID形式に応じてIDに強制する必要があります。 float入力値（4.0など）を含む他の入力値は、不正なタイプを示すクエリエラーを発生させる必要があります。

それは私に元の問題を残します。

私のPKが整数である mysql バックエンドがあります。

私の見方では、これらのオプションがあります：

  • PKのUUIDの使用を開始します。ただし、これには パフォーマンスへの影響 があります。
  • 暗黙的な要件（ relayjs エコシステムで発生）を無視して、アプリケーション全体でIDを一意にし、内部消費のためにIDを番号にキャストします。
  • ハッシュ アプリケーションデータレイヤーでIDをエンコードします。 UUID base64は、テーブル名とPK値の連結から派生します。

後者のオプションを使用します。これは、 graphql-relay-js が toGlobalId および fromGlobalId を介して採用したアプローチでもあります。

27
Gajus