Roadmap issue?

[yaacovCR]

Let's think big.

What do you want to see in terms of JavaScript graphql development?

This issue will hopefully get discussion going.

Feel free to start new issues as necessary.

You can use the linked list below for ideas that have already been mentioned.

New Features

Generation

• create new syntax for makeExecutableSchema that allows specification of SDL and resolver/other graphql config options on a per type basis (Add ability to implement schema using both SDL and GraphQLObjectTypes #185, Feature Request: Write typeDefs and resolvers together #1125)

Stitching

• add transform that creates AST for all types missing ast and allows adding directives to existing fields so that schema directives visiting can work (Make adding directives to existing fields easier when schema stitching #451)
• add FilterInputObjectFields transform (transformSchema: remove input fields by name. #1058)

Bug fixes:

• [ ]

Docs:

• add docs for full api including types (Lack of documentation on TS types/interfaces #1219)
• Add additional schemaTransforms examples, including:
  • schema transforms that adds resolvers and also wrap the schema with transforms that add fields to make sure the extra fields are always available (Add fragments in schema directives #984).
  • validating input on field resolvers rather than scalars so as not to add new types (feature request: functional directives #1234 (comment))
• Create new stitching examples, including:
  • stitching to relay-style subschemas with their own node fields (Thoughts on merging schemas that have their own Relay node lookups #1013)
  • batching (Batching requests to stitched schemas #884)
  • passing authentication data, closing (Stitching secure subscriptions using makeRemoteExecutableSchema #864)
  • caching using dynamic cacheControl hints (Can you do Apollo Server caching if you use schema stitching #1380)
• requireResolversForArgs and other resolverValidationOptions documentation says options will cause schema generation to throw an error when enabled, but no error is thrown -- a warning is printed to the console. It would be a breaking change to throw an error, but this should be better documented, with possibly a new flag considered to add the desired functionality if there is truly a need. Fixing the documentation addresses (resolverValidationOptions do not throw an error #1196)