stefangrimm commented on pull request #1: URL: https://github.com/apache/sling-org-apache-sling-graphql-core/pull/1#issuecomment-651733264
@bdelacretaz We need something like the suggested alternative to decouple what we're implementing on AEM's side from the Sling Core implementation. It's an important design goal for us to be able to use our implementation with other GraphQL frameworks as well, without requiring framework-specific code adjustments. With the current implementation, a scalar implementation would need to implement `SlingScalarConverter` directly, therefore adding a dependency on Sling. The proposed solution would allow us to use framework-agnostic implementations of scalars for our stuff. We would then adapt these scalar implementations to something that's suitable for the respective framework within the adapter bundle (that is required for each GraphQL framework anyway). There might be some other solutions (although I'm by far no OSGi expert, I guess we could register multiple instance of the same `SlingScalarConverter`-implementing wrapper component (one for each scalar) manually within the adapter, for example, but all the additional lifecycle-handling (when to register/unregister) frightens me). But from our perspective the proposed solution would be the simplest. If the proposal is not acceptable for you, we can also reduce the support for scalars in our code to the absolute minimum. At least for now we could live with this. Note that we don't have similar problems with data fetchers, as we're actually only using one single data fetcher and distribute it internally with the help of parameters (as part of the "fetch" directive) to our own, Sling-unaware data fetchers. cc @etugarev ---------------------------------------------------------------- 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
