I took a look at this today. So far I don't see this as a good solution if it requires people to use AddField rather than the field builders. This undermines much of our recent design changes, which encourage use of field builders and allows type inference and extension method use.

Now if there was a new base object type (e.g. SubscriptionObjectGraphType<T>) and the Field<T> methods on it all returned subscription field builders, that could be considered. But I fear that it will be a massive amount of duplicated code.

Another option would be to add SubscriptionField<T> methods that return a subscription field builder, but that doesn't seem to be much different than what we have now.

So far, I just don't see how the benefits outweigh the negatives. I'll be glad to review any options you may have.

It's also possible that I misunderstand your changes from my very-brief scan of the changes. I would like to see a sample of what changes are required for a typical subscription schema, both with auto registering graph types, and code-first. I'm not specifically seeing it yet.

It seems that you wrote another field builder, but unless I'm wrong, there's no way to use it. Let's assume you fix that issue. It seems like a lot of extra code and trouble for very little gain. In order to be worth it, this PR should prevent users from creating subscription fields at compile time.

For example, let's say you add SubscriptionField which creates a subscription field builder. There's nothing to prevent a user from calling Field rather than SubscriptionField. So we are back exactly to where we are now. The only difference is that the user has to discern between Field and SubscriptionField versus Resolve and ResolveStream. Given the two, I prefer the latter. Intellisense will show ResolveStream as an autocompletion when Resolve is beginning to be typed, whereas this is not the case with Field. Of course we could name it FieldSubscription but in the end, the user still needs to choose the right method.

We could take it even a step further, as I described above, where there is a dedicated SubsciptionGraphType. Then we could set Schema.Subscription to only allow setting a SubscriptionGraphType instance. The Field methods could be shadowed, so that the default ones are not accessible. Then we achieve compile-time checks.

So I would not merge yet. Certainly not as-is, with no way to use the subscription field builders.

All my comments apply equally to changes towards the goal of having input types disallow resolvers (which I endorse): the goal is met if compile-time restrictions are in place. Otherwise we have missed the goal.

Another thing I'm thinking, is that the subscription field type inherits from FieldType, so it could be assigned anywhere that FieldType is allowed. In other words, a stream resolver could be set for a non-root-subscription field. Maybe we need some type of inheritance:

• FieldType - abstract
  • ObjectFieldType - for output object types (adds FieldResolver)
  • InterfaceFieldType - for interface object types
  • InputFieldType - for input types
  • SubscriptionFieldType - for root subscription types (adds StreamResolver)

However, these changes might be drastic to implement. I think we should sit back when complete with whatever changes we come up with and consider: are the changes worth it? Probably, I think, but let's not presuppose that the answer is yes.

However, these changes might be drastic to implement.

I needed to start with something and I took the first step. Inheritance hierarchy looks like the second. I understand that in the end it may not work or will be too complex to programm. Nevertheless, after adding the latest changes to schema validator, I got the impression that eventually we can get a working solution.

However, these changes might be drastic to implement.

I needed to start with something and I took the first step. Inheritance hierarchy looks like the second. I understand that in the end it may not work or will be too complex to programm. Nevertheless, after adding the latest changes to schema validator, I got the impression that eventually we can get a working solution.

👍

Please ping me when this PR is ready for further review.

It is ready for further review. I added typed fields and new builders. In fact, the changes are not as dramatic as I thought.

TODOs/questions and pain points:

1. Connection builders. See commented code block in InterfaceGraphType.cs. Now ConnectionBuilder works only with ObjectFieldType but I think it should also support InterfaceFieldType. Also I see // TODO: Remove in v5 note in code.
2. Jumping around generics in TypeFields<T>/ITypeFields. Each derived field type has its own typed Fields property but also there is some code working with IComplexGraphType. See ComplexGraphTypeExtensions.Fields extension method, .Fields().AsEnumerable() usages and note about CS0695 error in TypeFields.cs.
3. Some aux methods have appeared like internal static QueryArguments? Arguments(this FieldType fieldType) => fieldType is IFieldTypeWithArguments ftwa ? ftwa.Arguments : null;
4. IComplexGraphType interface became empty. ComplexGraphType<TSourceType> class contains only ctor.
5. ObjectGraphType.CreateSubscriptionRootBuilder is still unused. I'm not sure how to be with SubscriptionRootFieldType - inherit it from ObjectFieldType or from FieldType. I tend to the former.
6. I do not like IFieldTypeWithArguments. Maybe change to FieldTypeWithArguments : FieldType? Not much better though.

I need time to review. Looking over only the API changes, I was thinking that perhaps there is an opportunity to turn some field builder methods into extension methods and perform some deduplication of code. Perhaps the field builders are merely interfaces. I have to review further.

Note that I think this PR is on the right track, but we should be careful to merge without a full review.

to turn some field builder methods into extension methods and perform some deduplication of code

I would not even if code is duplicated. The reason is different return types of builders to allow chaining.

Extension methods can still do this:

public static TBuilder DoSomething<TBuilder>(this TBuilder builder /* additional params */ )
    where TBuilder : IFieldBuilder
{
    /* do something */
    return builder;
}

Yes, they can. I have not yet evaluated what is better - to have separate builders or try to reduce the code to one class through extension methods.

I remembered why I did not use extension methods - all methods of builders are virtual.

Codecov Report

Merging #3583 (979dc3f) into develop (bc65011) will decrease coverage by 0.18%.
The diff coverage is 68.75%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@             Coverage Diff             @@
##           develop    #3583      +/-   ##
===========================================
- Coverage    83.99%   83.82%   -0.18%     
===========================================
  Files          383      390       +7     
  Lines        17066    17288     +222     
  Branches      2739     2768      +29     
===========================================
+ Hits         14334    14491     +157     
- Misses        2081     2145      +64     
- Partials       651      652       +1     

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.