Solution 5. passes criteria P.

[martinbonnin]

Solution 5. encourages users to use the existing syntax to express semantically non-nullable fields. It's doing so by changing the GraphQL best practices.

It obviously comes with the drawback of degraded support for non-error handling clients but that specific drawback is captured by criterias G. and O.

[benjie]

You've trimmed the part of the description that specifically relates to users migrating without hesitation, but that is the key part of the criteria. Users should be able to adopt the solution and mark semantically non-null things as semantically non-null without having to think too deeply about it, but solution 5 requires thought and planning, there are trade-offs that must be considered, and I don't think it will result in all semantically non-nullable positions being marked as such for teams who need to consider long-deployed legacy clients.

You say it is captured by G and O, but O is excluded and though solution 5 fails P for the same reason it fails G, they are not the same criteria and may apply differently to other solutions.

[martinbonnin]

I'm a bit wary of "without hesitation". All solutions have various drawbacks that may cause hesitation. For 5., it's degradation of legacy clients partial data. For 1., it's the fact that your backend team and frontend team have different representation of the schema and this may cause communication issues.

It's always going to be a tradeoff and hesitation is very difficult to objectively measure IMO.

Otherwise, I'd be ok letting this criteria go completely as we have quite a bunch already.