Support of `Long` (64-bit integer) scalar about graphql-spec

[leebyron]

It wasn't included because it's not available across all platforms, most importantly and practically in our case: JavaScript.

The GraphQL spec does not specify a maximum byte width or storage size for its Int and Float type, but there is a note about the caveat of platform specific restrictions. The two types only represent the semantic difference between whole and part numbers.

This means that you can use Int as a Long or Float as a Double as long as the platforms you're using support that size.

GraphQL allows you to define custom scalars as well, in the case that you want to distinguish between Long and Int, or define a custom serialization for it.

Custom scalars is how we expect these kinds of desired Scalars to be introduced in a way that doesn't burden spec-following GraphQL core libraries.

[coryfklein]

It wasn't included because it's not available across all platforms, most importantly and practically in our case: JavaScript.

Since 64-bit precision integers via BigInt were added to JavaScript two years ago it sounds like the primary objection to this addition is now obsolete.

Is there any reason we can't introduce a 64-bit integer at this point?

[coryfklein]

@leebyron and @OlegIlyenko I apologize for the at-mention but I wasn't sure you'd see replies on old closed issues like this.

What are your thoughts on my comment above, now that the landscape has changed a bit do you think it warrants a new GraphQL native?

Over the years this PR has accrued quite a high number of cross-references to PRs and issues in several other organizations that are having to work around the absence of a long-like type.

[OlegIlyenko]

Since spec explicitly states that:

If the integer input value represents a value less than -231 or greater than or equal to 231, a query error should be raised.

Does this mean that reference implementation does not conform to this part of the spec?

[LeeBurton]

It wasn't included because it's not available across all platforms, most importantly and practically in our case: JavaScript.

Since 64-bit precision integers via BigInt were added to JavaScript two years ago it sounds like the primary objection to this addition is now obsolete.

Is there any reason we can't introduce a 64-bit integer at this point?

I agree. I would like to hear their feedback on your question too. It has been almost 2 years and no reply - not great!

[OlegIlyenko]

Thanks a lot for the reply. I would agree with your suggestion to model it with custom/separate type. I would prefer to strictly define the capabilities of datatype, since it establishes a protocol between client and server, and they both need to know, whether number is bounded or unbounded and what is the maximum size. For that reason I created built-in/custom scalars for Int (32-bits), Long (64-bits), BigInt (unbounded), Float (64-bits) and BigDecimal (unbounded) in scala implementation.

The GraphQL spec does not specify a maximum byte width or storage size for its Int and Float type

This surprises me, because as far as I understood from the spec, Int GraphQL scalar type is 32-bit integer value:

The Int scalar type represents a signed 32‐bit numeric non‐fractional values. Response formats that support a 32‐bit integer or a number type should use that type to represent this scalar.

https://facebook.github.io/graphql/#sec-Int

The same is for the float:

The Float scalar type represents signed double‐precision fractional values as specified by IEEE 754.

Which means 64-bits (according to the standard: https://en.wikipedia.org/wiki/Double-precision_floating-point_format)

Did I misunderstood the spec?

[leebyron]

Sorry I may be quoting outdated information. It appears you are correct that we decided on stricter language for the spec out of concern for the exact reasons you brought up. I believe the JavaScript reference implementation is more lenient and allows up to 52bit Int (the max JS number type can represent)

[andimarek]

@leebyron The spec doesn't limit the size of int tokens:
http://facebook.github.io/graphql/#sec-Int-Value

The reference impl also doesn't check the size, so it is possible to create a custom long scalar which allows the usage of int tokens (literals) as input. See https://github.com/andimarek/graphql-java/pull/94#issuecomment-190008636.

Is this intended or just a gap in the spec and the size of the int token should be limited?

Thanks!

[leebyron]

This is intentional. Note that the same is true for many programming languages including JavaScript. You can type a number in syntax that's larger than what the underlying memory can represent.

In GraphQL's case it's also useful for exactly what you mentioned: being able to create custom scalars which represent large numbers.

[leebyron]

However the Int scalar type does enforce 32bit both in spec and the reference implementation to be maximally compatible.

[andimarek]

Thanks for the quick response.

[dehamzah]

here is specification doc of Int http://spec.graphql.org/June2018/#sec-Int

in case someone goes here and want to know the maximum value of Int. You must do 2^31 - 1.
Because the docs said:

If the integer internal value represents a value less than -2^31 or greater than or equal to 2^31, a field error should be raised.

[benjie]

If someone wanted to champion this change to the GraphQL specification the process to do so is to read the Guiding Principles, write an RFC (can be as simple as a new issue with a rough idea, a document filed into this folder, or could be actual spec edits in a PR), and then attend a GraphQL Working Group and get feedback on your proposal and go from there. Working groups are open to everyone, there's a small agreement you need to sign before attending and then you can add yourself to an upcoming agenda, e.g. April's primary: https://github.com/graphql/graphql-wg/blob/main/agendas/2023/04-Apr/06-wg-primary.md

Changes like this don't happen without a champion, and currently this change does not have a champion (and, sadly, @OlegIlyenko is no longer with us). If you want to see this change, be the champion of it! If you want further advice on how to be an effective champion, feel free to reach out to me in the #graphql-spec channel of the GraphQL discord (https://discord.graphql.org) - I'm @benjie#5432 - or ask below.