Add introspection support

[kulshekhar]

The lack of introspection in the current version of SC means that we don't get the type safety for client side queries that we get with most other GraphQL server side implementations. While the dynamic nature of SC lends itself to extremely rapid prototyping, this becomes a hindrance when you want to 'lock things down' after the experimental phase. Having introspection/schema checks available at build time removes the need for a whole class of integration tests.

To start with, this can be built on top of any schema that the user might add. SC lets users add schema that is currently used for validation of field types. This schema could potentially be used as the starting point when adding the introspection capability.

Now this schema could also be directly used for type checking at compile time but then there's the risk of divergence between this schema and the server. That's why it'd be better to have the SC server allow introspection even if it were to be based on a manually supplied schema.

[YourTechBud]

That is a great suggestion.

The problem with here is that, SC is schemaless at its core. We need to support databases like Mongo where the user might not want to define a schema. Also, we allow creating GraphQL apis on top of existing REST APIs without having to provide a schema.

To make things a lil more complex, SC allows users to join various datasources on the fly even if the relationships weren't defined upfront.

This makes adding support for introspection extremely tricky since a vast majority of SC features (related to schemaless GraphQL) will pop up as errors by linters.

this becomes a hindrance when you want to 'lock things down' after the experimental phase

This is a common feature request we have got. Thats the reason why we added support for templated SC queries which let you write your final query in SC itself so the frontend need not worry about it.

[kulshekhar]

We need to support databases like Mongo where the user might not want to define a schema.

The GraphQL schema is typically orthogonal to what's used in the backend. You could have a well typed GraphQL schema backed by a schemaless data store.

That said, whether to support this or not is a design decision and completely your prerogative. I respect that.

The ability to fix GraphQL query errors at edit/compile time (compared to run time) is a massive improvement in DX so I hope you would reconsider this at some point in the future :)