Add introspection support #1357
Replies: 1 comment 1 reply
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions