[Proposal] Allow passing a custom json marshal/unmarshal implementation

[ManiacMaxo]

Currently the json marshalling cannot be easily replaces with a different implementation like https://github.com/goccy/go-json or https://github.com/json-iterator/go. The only way to do so would be to copy the transport implementations and inject the json marshaller there.

I propose an API that accepts a custom implementation supplied directly to the transport at fields:

type Decoder interface {
	Decode(v interface{}) error
	UseNumber()
}

type Json interface {
	Marshal(v interface{}) ([]byte, error)
	NewDecoder(r io.Reader) Decoder
}

type POST struct {
	// Map of all headers that are added to graphql response. If not
	// set, only one header: Content-Type: application/json will be set.
	ResponseHeaders map[string][]string
	Json            Json // Json being an interface so it can be implemented however the user wants
}

The library can supply a default implementation based on encoding/json:

var DefaultJson Json = jsonImpl{}

type jsonImpl struct{}

func (jsonImpl) Marshal(v interface{}) ([]byte, error) {
	return json.Marshal(v)
}

func (jsonImpl) NewDecoder(r io.Reader) Decoder {
	return json.NewDecoder(r)
}

Since there already exists a file that handles most json marshalling it can be updated to accept the json implementation and fallback if one is not supplied:

func writeJson(json Json, w io.Writer, response *graphql.Response) {
	if json == nil {
		json = DefaultJson
	}
	b, err := json.Marshal(response)
	if err != nil {
		panic(err)
	}
	w.Write(b)
}

This will add a slight overhead of checking for the implementation but will not break existing codebases.

[StevenACoffman]

The only thing I'm wondering about is the use of the global variable instead of a config option:

var DefaultJson Json = jsonImpl{}

However, this proposal seems like a pretty good way for the community to experiment with different libraries.

In #3161 there was a revised attempt to adopt goccy/go-json with benchmarks that showed JSON encoding was a more significant performance improvement than when it was first proposed.

However, several people in the community have warned me against defaulting to using goccy/go-json as in this comment, so I have held off on making it the only way for gqlgen to work.

In #2757 it was suggested that there are more than one alternative JSON encoding library people might want to use.

Some of these libraries include:

• go-json-experiment/json - Go json/v2 WIP
• goccy/go-json
• json-iterator/go
• bytedance/sonic
• segmentio/encoding
• mailru/easyjson
• minio/simdjson-go

Your proposal would make it easy for us to swap in an alternative and do comparative benchmarking. Those who want to benefit from improved performance while accepting a higher risk of bugs can do so without breaking anyone else's existing production environment.

[StevenACoffman]

The open source usage for the various libraries shows that json-iterator is actually more widely used than go-json in the ecosystem.

Popularity	Order by stars	Order by Page rank
json-iterator/go	Order by stars: 211	Order by page rank: 77
mailru/easyjson	Order by stars: 845	Order by page rank: 203
goccy/go-json	Order by stars: 1222	Order by page rank: 374
bytedance/sonic	Order by stars: 44350	Order by page rank: 427
segmentio/encoding	Order by stars: 3188	Order by page rank: 1079
ohler55/ojg	Order by stars: 3618	Order by page rank: 1790
go-json-experiment/json	Order by stars: 6616	Order by page rank: 3866
minio/simdjson-go	Order by stars: 1971	Order by page rank: 5313
wi2l/jettison	Order by stars: 12070	Order by page rank: 5979

[StevenACoffman]

Extensive testing and performance results for various libraries are here: https://github.com/go-json-experiment/jsonbench