-
-
Notifications
You must be signed in to change notification settings - Fork 568
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
Aliasing undesirable field names #34
Comments
How about implementing the alias by reflection over the GraphQL schema?
So the dev needs to create empty Types/Queries (empty as in only name is set but no fields or resolvers), and then pass both source and target to the Weak Map that's argument of some function. This way it's possible to customize the new endpoint with virtual fields that don't require a trip to Postgres. The aliases can be kept in a different file from the generated schema as for easy SQL schema updates. I'm unsure when this should happen. At Postgres reflection time, node.js server initalizing, sowhere in between? Edit: I just noticed that it could also be possible to copy fields and methods from the referenced GraphQL objects directly within JavaScript without actually querying the GraphQL server. |
Isn't this what you're looking for? If so, then a simple JSON map passed in might be enough for us. |
@burkhardr No, that's not what where are trying to achieve. We want to alias the Query-definitions, because the Relay-compliant schemas aren't that human friendly. |
Well, you could do that server-side, but the GraphQL connections / edges are named like that for a reason. The link I posted above allows you to do aliasing on the client-side, which - while not as convenient - is definitely the easier solution. |
This issue discusses a server side implementation. The thing with the alias in the query is that it's just working on one level. With the built-in alias the only thing that actually happens is that the returned key has a different name, paths can't be simplified however. The primary function for alias is to be able to request and return multiple instances in one request. By design this GraphQL query is impossible to fulfill:
Because it's impossible to return both objects on the same The aim of the discussed alias function is to make querying nicer, the builtin function just complicates the query as it's longer:
|
If you think of GraphQL as a straight REST replacement, then data structures like If you're willing to sacrifice that for added simplicity, then this feature should be strictly opt-in. |
I don't understand why the feature should be opt-in. Can you elaborate? |
I finding a better name for fields like What do you think about using constraint names for these field names? So if the reference to Making connections optional is something I've discussed with @rattrayalex in #16. I don't really like the idea because it duplicates a lot of logic, but if enough people articulate a want/need I'll reconsider. I really think solving the |
Connections themselves shouldn't be optional. Inferring the name of the connection from the FK/column name makes sense to me, but you'll still not arrive at something like Sorry for the confusion. My sole argument was around not being able to boil a graph down to the same format you'd get from a classical REST endpoint without sacrificing some of its functionality. |
Closing in favor of a discussion in #42. |
It seems like what a lot of people find undesirable about PostGraphQL is how fields are named. How can we build a system (whether it be a JSON map or otherwise) which allows people to rename automatically named fields?
Any ideas are welcome, I'm have no ideas at the moment.
The text was updated successfully, but these errors were encountered: