GraphQLIntの代わりにGraphQLIDを使用するのはいつですか？

Question

GraphQLIntの代わりにGraphQLIDを使用するのは明確ではありません。 Query.userの場合

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

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

が、GraphQLIDまたはGraphQLIntを使用するかどうか違いはありませんように見える：

は、次のスキーマを考えてみましょう。

User.idの場合、GraphQLIDを使用すると入力を文字列にキャストします。 GraphQLIntを使用すると、入力が整数であることが保証されます。

これにより、クエリと型のシステムが矛盾します。

graphql-jsspecは、単純に言う：IDを表し

GraphQLScalarTypeを。

（例えばGraphQLクライアントは、いつそれができる整数にGraphQLIDをキャストしなければならない）、これは実装の詳細であるか、それはIDは常にgraphql内の文字列であることが期待されますか？

Answer 1

私はGraphQL仕様を見てきました。

IDスカラー型は、オブジェクトを再フェッチするために、またはキャッシュのキーとしてよく使用される固有の識別子を表します。 IDの型はStringと同じ方法でシリアライズされます。しかし、人間が読めるようには意図されていません。それはしばしば数値ですが、常にStringとしてシリアル化する必要があります。

- それは実装に左または仕様によって決定されているかどうかの質問に答えるhttps://facebook.github.io/graphql/#sec-ID

、つまりIDはStringに常にシリアル化する必要があります。

さらに、入力型の文脈では、入力は文字列に強制される必要があります。スペックから：

入力強制（例えば、4）入力値が適しとしてIDに強制されるべき入力タイプ、または整数（例えば"4"など）任意の文字列として期待

与えられたGraphQLサーバが期待するIDフォーマット。浮動小数点入力値（4.0など）を含む他の入力値は、誤った型を示すクエリエラーを発生させる必要があります。

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

mysql私のPKは整数です。

私はそれを見る方法、私はこれらのオプションがあります。

• スタートのPKのためのUUIDを使用しました。ただし、これはperformance implicationsです。
• ID番号をアプリケーション全体で一意にする暗黙の要件（relayjs生態系由来）を無視し、可能な場合はIDを内部消費用にキャストします。
• ハッシュ アプリケーションデータレイヤーのエンコードID。 UUID base64テーブル名& PK値の連結から派生したものです。

私は後者のオプションを使用します。これは、がtoGlobalIdとfromGlobalIdで採用しているアプローチです。