Clarify (and secure) future status of ServiceAttribute

[RoystonS]

Product

Hot Chocolate

Is your feature request related to a problem?

The migration documentation for v13-v14 states
"It is no longer necessary to use the [Service] attribute unless you're using keyed services"

and

"Support for the [FromServices] attribute has been removed. As with the [Service] attribute above, this attribute is no longer necessary."
"Since the RegisterService method is no longer required, it has been removed, along with the ServiceKind enum."

This suggests that there's a intention to remove the [Service] attribute in future and the only reason it has stayed is to satisfy the requirements of keyed services?

However, I'd like to suggest that there are still excellent use cases for the [Service] attribute, and would like to request that it not be removed in the future, even if another way of indicating service keys is found. Particularly when writing unit tests for resolvers it's incredibly useful to be able to mark resolver parameters as being sourced from a DI system without having to put them all in the DI system:

1. In our codebase we have a lot of unit tests for resolvers. If we're testing resolver Q, we will boot up a DI container that provides the appropriate (real or fake) implementations of services required by Q, fire up a HotChocolate OperationRequestBuilder and execute the request.

   With explicit [Service] attributes this works very well: HotChocolate scans all the available queries, mutations and subscriptions (thanks to HotChocolate's excellent type module code generation), runs the query and we have nicely-executing tests.

   However, if we attempt to remove those [Service] attributes with v14, HotChocolate now relies upon the DI container having every possible service configured for every resolver, even though we're only testing resolver Q. It's scanning all of the resolvers in all queries, mutations and subscriptions, not just the Q resolver that we're testing, and because we've only configured the dependencies for the Q resolver, HotChocolate incorrectly concludes that there are a lot of extra non-DI parameters for all those other resolvers, many of which can't be serialised (because they're really .NET services), and the compilation of the overall schema fails.

   We thought of 4 ways of working around this:

   1. Have every unit test configure every possible service in DI for every possible resolver, thereby providing the information that HotChocolate needs to figure out which resolver parameters are coming from DI and which aren't. This is quite a lot of work, and would make it harder to vary the DI configuration from one test to another (we use fake implementations of one service in one test and real in another) and the extra DI configuration would slow down all tests.
   2. Stop using the auto-generated type module in the unit tests, and somehow configure only specific top-level queries/mutations/subscriptions test-by-test. This would be pretty fiddly, and still have many of the issues of the above option.
   3. Keep using explicit [Service] annotations on parameters that are coming from DI. That way HotChocolate isn't reliant upon all of the services being in the DI container.
   4. Use RegisterServices to tell HotChocolate which are injected services and which aren't. Unfortunately, that was removed in v14.

   We've gone for option 3, as it's the simplest - and obviously because we were migrating from v13 we already had all those attributes in place.

   So right now we're benefiting massively from HotChocolate's ability to detect that a resolver parameter should come from DI without having to actually configure that in the DI system.

2. We're finding that having explicit [Service] attributes on DI-injected resolver parameters makes it easier to read those resolver signatures. It's more obvious which are the 'real' (GraphQL-provided) parameters and which are service-injected. (This is absolutely a minor stylistic preference, however.)

The solution you'd like

We'd very much like the HotChocolate project to state that the [Service] attribute will be kept and not removed in the future, and this to be added to the documentation.

Right now the documentation - and what's happened to [FromService] and RegisterServices - implies something of a level of deprecation, which makes my team a little nervous: removing support for [Service] would make testing significantly harder.

[michaelstaib]

There is no intention to remove the [Service] attribute. While its not needed some people might want to be explicit about semantics. In the same way we also have an [Argument] attribute, although this is not needed. This aligns with what the ASP.NET core team has done for minimal APIs.

Summing this up: We will not remove the [Service] attribute in the foreseeable future.

[RoystonS]

@michaelstaib That's excellent news. Thank you.