Add spec for Long custom scalar type

[jakobmerrild]

The Long data type is commonly used in many applications because the largest value that can be held in an Int value is 2^31-1. See: graphql/graphql-spec#73

I'm honestly torn about whether or not output strings should be allowed 👀 . As discussed in the linked issue common clients (JavaScript) does not read JSON numbers above 2^53-1 into number without loss of precision.

Also accepting String inputs without accepting String outputs seem inconsistent.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jakobmerrild / name: Jakob Merrild (086bfff, 28ba686, 5ea5538, 622cc03, 66fb671, b648fa5, e20ed45, efeab84)

[martinbonnin]

Thanks for looking into this.

I left a few comments mainly FYI. Feel free to use them or reject them, this repo is made so that we don't have all to agree. Just resolve the comments you reject so we can know when to merge this.

[benjie]

Though it makes sense to use IntValue when parsing literals, for serialization I think you should definitely use strings, at least in JSON. For example, if you use to_json on a bigint in Postgres it will output a long number, which JavaScript can then not process, causing tremendous headaches. JavaScript will NOT change this, doing so would be a breaking change which is antithetical to JavaScript's design goals, so this is something that we have to live with.

Using a numeric format when serializing to JSON would make programming languages which don't have native support for parsing arbitrarily long numbers in JSON have to use a custom JSON parser for all payloads sent using the most common HTTP encoding. That's not really viable, and will result in few people adopting Long.

Instead, I'd recommend that you require string in both directions, at least for JSON.

Note this text from the spec:

a GraphQL service could define a scalar called UUID which, while serialized as a string, conforms to RFC 4122. When querying a field of type UUID, you can then rely on the ability to parse the result with an RFC 4122 compliant parser. Another example of a potentially useful custom scalar is URL, which serializes as a string, but is guaranteed by the service to be a valid URL.

Serializing to string is perfectly valid, and is a safe fallback for basically everything. Even binary can serialize as string via base64/etc.

[martinbonnin]

@jakobmerrild did you want to update this to use Strings in both directions? (or limit the range to something that JS can parse?)

[jakobmerrild]

@jakobmerrild did you want to update this to use Strings in both directions? (or limit the range to something that JS can parse?)

Yes! Sorry, I've been busy with other work. I'll try to get to this later today

[jakobmerrild]

Aaaand, I got distracted again. Have updated the spec to:

1. Conform to the template-string template
2. Specify that serialisation is supposed to be to/from string values

[martinbonnin]

@jakobmerrild thanks for updating this PR. We have a few CI failures. Mind looking into those? I think we can merge after that.

[martinbonnin]

All good ✅ @jakobmerrild is it ok to merge this pull request?

[jakobmerrild]

All good from my end 👍

[martinbonnin]

All good from my end

It's the important end :)

As detailed in the README, feedbacks may not block the merging of a new scalar specification. The authors has final say. Merging this.

[martinbonnin]

Thanks for the contribution!