Skip to content
This repository has been archived by the owner on Oct 11, 2024. It is now read-only.

Use strings in GraphQL schema instead of custom scalars #901

Open
albrow opened this issue Aug 10, 2020 · 0 comments
Open

Use strings in GraphQL schema instead of custom scalars #901

albrow opened this issue Aug 10, 2020 · 0 comments

Comments

@albrow
Copy link
Contributor

albrow commented Aug 10, 2020

When designing the GraphQL schema in #858 I used custom scalars. Now that all the pieces are in place and I understand more about how GraphQL client code works in a handful of languages, it looks like there is not good enough support for custom scalars on the client side to justify using them.

The idea behind using custom scalars for BigNumber, Hash, Address, etc. was that clients can determine how to encode/decode from the scalar type to the appropriate native type (e.g. in Go *big.Int, common.Hash, and common.Address). In practice, support for this kind of encoding/decoding is poor or non-existent for most popular languages and clients. machinebox/graphql has no awareness of custom scalars and you have to manually convert to the appropriate JSON or GraphQL representation. Apollo Client has very limited awareness of custom scalars. You can use type aliases to tell Apollo Client what underlying type to use (e.g. type Hash = string) but you cannot tell it how to automatically encode/decode that type. Again, we need to do that manually.

We do have pretty good support for custom scalars from gqlgen, but even that is not perfect (see 99designs/gqlgen#1259).

At this point, it seems clear that using strings in the schema will be more straightforward for clients to consume. This will also more closely match the internal type representation we use inside Mesh if we implement some of the suggestions in #900.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant