Skip to content
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

extract relay classes to interfaces and implementations #267

Merged
merged 3 commits into from
Jan 27, 2017

Conversation

jimexist
Copy link
Contributor

No description provided.

@dminkovsky
Copy link
Contributor

Can I ask generally—what's been your experience with the Relay classes? Personally, I've not found them very useful. I am wondering if I am using them incorrectly.

@jimexist
Copy link
Contributor Author

@dminkovsky did you mean the relay as an idea or the relay implementations in this repo?

  1. as an idea i could appreciate relay's approach to consolidate and decide on some standard (but not necessarily the only) way of implementing object identification (Node) and relationships (Connection) - the point is that for a sophisticated enough application there is going to be one, and relay just happens to be a good standard people could follow and they've already got better documentation than I personally could come up with so I would stick to that
  2. as an implementation I would argue that this package is preliminary. Relay should've been a utility class rather than a new-able one, and the connection class support is lacking.

For 2. I can volunteer to contribute. I wouldn't call one's usage of relay incorrectly considering that it is just an idea and a proposed implementation - there is no absolute standard that one must follow.

@dminkovsky
Copy link
Contributor

I meant the Relay implementations in this repo. I am a really big fan of Relay the front-end library, so let's skip (1).

Regarding (2), the inability to set data fetchers on the fields generated by the Relay class methods have made using the class for me problematic. Do you just work with the default data fetcher?

@jimexist
Copy link
Contributor Author

@dminkovsky i did find the type resolving of Node requiring a bit more efforts - especially when the individual types depend on the Node interface while the latter depend on individual types as well - this circular dependency requires more efforts (I am using Guice). But other than that - I am using Pojos in data fetcher's return value and then rely on getters to fill the fields on GraphQLTypes

@jimexist
Copy link
Contributor Author

jimexist commented Dec 30, 2016

... missed one point, I am also using Jackson's data mapper to do convertion between Pojo's and Map<String, Object> - can't really go beyond that because Java is relatively lacking the support for type magics.

@bbakerman bbakerman merged commit f4ebaa1 into graphql-java:master Jan 27, 2017
@jimexist jimexist deleted the feature/connection-interface branch January 27, 2017 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants