Use strings in GraphQL schema instead of custom scalars

[albrow]

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.