Rule 2.2 may be anti-pattern in some cases

[VadimZhiltsov]

Nowadays GraphQL is a pretty common option for Backend For Frontend (BFF) services.

Rule 2.2. may do bad bad favor if you do not fully have control over the data you expose to the client.

Problem example
Schema

type User {
    status: StatusEnum
}

 enum StatusEnum {
    ACTIVE
    PENDING
    REJECTED
}

Resolver

module.exports = {
  Query: {
      users: () => {
           return axios.get('https://user.microservice.com/api/users')
      }
}

And in this case, the enum definition of this schema is an antipattern, as at one day user microservice may be changed and new status is added, but BFF is gonna be stale.This will cause errors and the client may not get a response, as new status is absent in StatusEnum For such cases is better to pick string type, as enum is not failure-tolerant.

So I suggest clearly express to user, that this rule should be applied only if GraphQL service has control over the data

[RIP21]

This is actually a good point. I encountered it myself while doing BFF.
I was handling it in a way that all input types were getting actual enum types for autocomplete in tooling etc. while fetching all fields that were ENUMs were strings with documentation that was telling that there is actually an ENUM in the schema with name N, which they can look up themselves.
I guess this note may be a nice addition to the rule as a warning for such a use case.

I think if a PR would be open it will be merged :)