Interfaces

[chih-chen]

Interfaces

[swalkinshaw]

Great questions.

But imagine if one day it is necessary to add new fields which is ManualCollection specific.

The solution depends on how generic you can make these fields in my opinion. As you mentioned, CollectionRule was made more generic and the empty list is a fine trade-off which still makes some semantic sense.

A decision like this is more of a spectrum, not really a simple binary choice. In our case (and the tutorial's), there aren't enough reasons to use an interface. But if you start adding more differences, then maybe an interface does make more sense. In the end it's your API and up to you anyway 😄

[eapache]

Another solution (and one that we use internally in a few places - we should find a way to work it into the tutorial somehow) is to use a union on the differing fields. Something like:

type Collection {
    ...
    specificFieldSet: SpecificFieldSet!
}

union SpecificFieldSet = CustomCollectionFields | Collection2Fields | Collection3Fields

The advantage of this is that often you can find a better semantic name than SpecificFieldSet. For example, say that the collections were different specifically in how products were sorted (and these specific field sets implemented different approaches to that). Then you could call the field and union productSortDetails: ProductSortDetails! and it's much more obvious what it does and why.

Internally we call this concept "pushdown polymorphism" because you're pushing the polymorphism (which is technically on the collection) down into the specific semantic dimension of difference.

[chih-chen]

The solution depends on how generic you can make these fields in my opinion.

Great point! I believe that ManualCollectionFiledSet is a generic field, if it is null, it means that these fields are not applicable for a AutomaticCollection, so still have some semantic meaning. It also follows the rule 6:

Rule 6: Group closely-related fields together into subobjects.

So I followed this principle, but I don't know if it is a good practice.
Because, imagine if there are 10 types of collection, and each type has a set of specific fields and I would like to query all these specific fields. In this case, what I need to do is:

query {
    collections {
        fieldSet1 {
              ...
        }
        fieldSet2 {
              ...
        }
        fieldSet3 {
              ...
        }
        fieldSet4 {
              ...
        }
        fieldSet5 {
              ...
        }
        fieldSet6 {
              ...
        }
        ...
    }
}

These would lead a lot of null values, each collection would have 9 fieldSets null and 1 fieldSet with some value. Quite bad.

A decision like this is more of a spectrum, not really a simple binary choice.

Yeah, but it would be awesome to have some guide for this situation, because people may understand that interfaces are not necessary and specializations are all detail implementation.

[chih-chen]

Nice point!
I believe that for my situation, some specialization is required. So I will go with interfaces or unions.
There are some awesome articles talking about these topics:

• GraphQL Interface and Unions -  how to design GraphQL schema
• GraphQL tour: Interfaces and unions

Maybe these tips could be added to the tutorial somehow.
Thanks for the discussion, it was really helpful and constructive! Closing this issue.