You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This library follows a schema-less approach, but I was wondering whether a schema-based option is not worth considering.
Adding a schema in the mix could have a couple of advantages:
a more optimal conversion that leads to better performance (queries are predictable)
clarity for client developers by supporting graphiql, etc.
compatibility with other graphql tools;
it's complimentary; supporting a graphql schema does not prevent the current approach
no need to start from scratch, there are plenty of examplesoutthere in other programming languages.
(this could be something we can put a bounty on)
The text was updated successfully, but these errors were encountered:
This may indeed be useful in cases where a fixed source (or federation of sources) is known beforehand, where the schema of that source could be used to more conveniently write queries.
It may even be possible to automatically generate this schema from the sources through introspective SPARQL queries on the source (and possibly also on the used RDF vocabularies).
Feel free to mail me if you want to discuss putting a bounty on this! (if we want to include schema generation, this may also be suitable as a research project)
Would love to second generated a graphql schema automagically – that would be very neat. Right now Im trying to integrate GraphiQL into my app, and a magic schema would be cool
This library follows a schema-less approach, but I was wondering whether a schema-based option is not worth considering.
Adding a schema in the mix could have a couple of advantages:
(this could be something we can put a bounty on)
The text was updated successfully, but these errors were encountered: