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


Reply via email to