bdelacretaz edited a comment on pull request #1: URL: https://github.com/apache/sling-org-apache-sling-graphql-core/pull/1#issuecomment-651638364
We used to have a similar design for the SlingDataFetcher initially, with a single OSGi provider service which provided multiple data fetchers. Changing that to a design where SlingDataFetchers are individual OSGi services allowed me to remove a lot of code, especially in the [samples website](https://github.com/apache/sling-samples/tree/master/org.apache.sling.graphql.samples.website) This makes me think that my original design (at commit 99062b5ba) where each SlingScalarConverter is an OSGi service, using the OSGi framework to select them, is more consistent with the data fetchers part, and also likely to lead to simpler client code. What advantages do you see in your alternative design? If the goal is to reduce the number of classes that you have to implement, we might also allow a ScalarConverter to register several names, or name patterns (if that's efficient enough - but selection can be cached if needed). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
