Store parsed Schema on ExecutableSchema rather than use global variable

[gitxiongpan]

This PR moves from using the global variable parsedSchema to storing it on the ExecutableSchema.

---

In my use case, I have two GraphQL servers. One server's schema is trimmed down and it is publicly accessible. Another one has a comprehensive schema and it is protected by a gateway

I would like an easy way to implement these two GraphQL servers. At the moment executableSchema.Schema() returns a global variable parsedSchema. This behavior makes my use case quite challenging to solve.
see code below

//go:embed "schema.graphql"
var sourcesFS embed.FS

func sourceData(filename string) string {
	data, err := sourcesFS.ReadFile(filename)
	if err != nil {
		panic(fmt.Sprintf("codegen problem: %s not available", filename))
	}
	return string(data)
}

var sources = []*ast.Source{
	{Name: "schema.graphql", Input: sourceData("schema.graphql"), BuiltIn: false},
}
var parsedSchema = gqlparser.MustLoadSchema(sources...)

......

func (e *executableSchema) Schema() *ast.Schema {
	return parsedSchema
}

I updated the codegen/generated!.gotpl so that executableSchema is configurable

This update is backward compatible which means the change is almost transparent to those with no interests in hosting multiple GraphQL servers with different exposed schemas.

I have:

• Added tests covering the bug / feature (see testing)
• Updated any relevant documentation (see docs)

[coveralls]

coverage: 75.938% (-3.3%) from 79.212% when pulling 7bc43de on gitxiongpan:codegen/configurable-executableSchema into 4e8d8c7 on 99designs:master.

[gitxiongpan]

I reckon line 277 and 284 have better coding style no matter we decide to make executableSchema configurable or not

[StevenACoffman]

Avoiding global variables is good, but ec.Schema().Types[name] violates the Law of Demeter.

If any of ec, ec.Schema(), or ec.Schema().Types are nil, this will have a fatal error (panic due to nil pointer dereference) at this line, and from alone it would be difficult to figure out which of these was nil.

A temporary local variable might be more verbose, but in the event of a nil pointer dereference, the line number would then tell you immediately which of those three cases was problematic.

[gitxiongpan]

feel free to have a look of my different implementations with vs without this PR
with: https://github.com/gitxiongpan/gqlgen-todos/blob/main/server.go
without: gitxiongpan/gqlgen-todos@548f492#diff-03953400a30cac7024178bcd525b15c8f4329ae75ed1a57c8041026d0131d36f

[gitxiongpan]

screenshots for visual demo

[StevenACoffman]

Hey it looks like you need to regenerate:

go generate ./...; cd _examples; go generate ./...

[gitxiongpan]

Hey it looks like you need to regenerate:

go generate ./...; cd _examples; go generate ./...

Thank you! It is my first time working on codegen feature. I didn't know I need to regenerate.
Regenerated, please let me know if I am still in the wrong trrack

[gitxiongpan]

I can see that Link/lint(1.19) is failed. I am not sure how I could fix it though.

[StevenACoffman]

Thanks for this PR! I reworded the PR title and description so that it was a little easier for others to see what changed and why. I also regenerated the _examples directory, which is a separate module so your earlier go generate ./... would have ignored it.

I'm looking forward to your next PR!