Support of `Long` (64-bit integer) scalar

[OlegIlyenko]

In my experience long is pretty common primitive data type. It also used to represent pretty common things like timestamps or cent amounts. As a result of it, most of modern programming languages naively support 64-bit integer values in one form or another. Is there particular reason why long scalar type was not included in the 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.

[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)

[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?

[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.