New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return types dependant on the arguments #13
Comments
Might be that I should have created that in spec repository, I can move it if you want. |
No problem for it to be here, this is a great question we spent a lot of time talking about when assembling the spec. Ultimately, we decided that it was beneficial for the return type of a field to always be the same regardless of arguments (e.g. no overloading) because it dramatically simplifies introspection which means less friction to building great tools. We work around that in two ways: If you know the type that is going to be returned apriori, then it's best if your type system exposes a field that documents that. It allows tools to be smarter and often is nicer to read. To build upon your example:
For fields on the top level, this pattern of For fields where you can't apriori know the exact return type, and you're using one of the abstract types (interface types and union types) then fragments are the tool to use. Here's an example showing inline fragments, which are useful for this case, but you could also use defined and referenced fragments to identical effect:
We use this pattern a lot at Facebook, where we refer to a lot of things generically. For example if we're trying to load data to prepare |
Thanks! Follow-up question - in our system user there are calls to dynamically update the schema, eg
Should |
That's pretty cool that you've got a dynamic schema like that. One thing to be cautious of is to ensure that "breaking changes" to an API like this won't break any existing consumers of your API, but there are definitely circumstances where this sort of dynamic schema is powerful. Fast prototyping comes to mind. We don't present type names as an Enum, we considered it but decided that it was an unnecessary complication. There are definitely some perks like ensuring statically that any references to types are correct, but there are really just a few places where that's the case. You could also imagine that with a dynamic schema API like that, it could be easy for the Enums to get out of sync if two clients are calling |
I don't really see a way to prevent such race conditions apart from locking the API during schema changes, which isn't very developer-friendly. We assume people would use best judgment and won't modify their schema too much when they are out in production. It seems to work fine for, eg, Parse. As for dynamic schema - we just serialize parts of the schema that can be modified and restore the schema to 'native' format before query execution. Our schema language is quite similar to the one in reference implementation (albeit much more crude and hacked together), so it shouldn't be a big problem for us to move to FB schema language. |
Absolutely, just something to keep in mind. I would be cautious of any kind of schema-modifying public API for a public service because of nefarious actor concerns (what happens if someone runs Thanks for the great questions! |
@leebyron sorry to necromance this issue but we're having trouble using this polymorphic functionality. When requesting by interface name, the returned values are also of the interface type, not of the concrete type. We can try to introspect via How can we find out the specific types of items returned when querying by interface? |
Can you expand on this? Perhaps with some links to code examples? The purpose of |
It seems like we may have had a bad release, upgrading to latest graphql-js fixed |
Me and @fson at reindex.io have been working on the GraphQL implementation ourselves, ever since it was announced. Super cool stuff!
One issue I've encountered trying the reference implementaion: In our system we have fields in
RootQueryType
whose return type is dependent on thetype
argument.Is it possible to do such thing with reference implementation? I've found 'resolveType' for interfaces, but that seems to be for having
... on Type
query fragments.It is possible to just replace those generic fields (we have
node
,nodes
,create
and many more like that) with concrete fields like getUser, createUser (and that was our original plan when we started), but we feel that generic fields we ended up with are easier to use.Thanks!
The text was updated successfully, but these errors were encountered: