GraphQL and strongly-typed languages like c#, continued from other thread

[rivantsov]

This is a continuation/follow up of the discussion originated in 'namespaces' issue in graphql-spec repo. The problem of strongly typed languages was out main line there, so I moved it here. The original post of the branch:

graphql/graphql-spec#163 (comment)

[rivantsov]

@b-jsshapiro,
So as far as I got from your post about challenges you faced, here's my interpretation and thoughts.

1. Strong types in c# client.
   You need strong typing on the client, all SDL types (input and output) represented as POCOs. Plus partial types coming from 'queries' - let's leave them for later.
   So as for having POCOs for model types, it looks like the Model-first approach would be what you need. The SDL model is expressed as a set of c# classes, with special attributes and some extra settings. Plus, what's important, the POCO classes are really POCO, do not carry heavy references to server-side infrastructure.
   This is the approach of NGraphQL, it's actually the ONLY path supported, Model-first; no Schema-first or code-first. The POCO classes you create to express your server GraphQL model, these POCOs can be directly used on the client, even restricted client like WebAsm Blazor. The POCOs reference only NGraphQL.dll which is super-light (28K), contains only very basic abstractions - exactly for this reason, to make it possible to reuse the model POCOs on the client.
   The challenge with schema-first and code-first paths is that you never get/produce clear strong types representing types in schema; looks like HotChoc added what they call Annotation-based approach, which involves POCOs, but can it be used directly on the client is unclear. Anyway they generate all client-related stuff explicitly.

2. Strong types for query results
   As for types/classes that can be derived from the actual queries returning 'partial' objects (with subset of fields) - I have some ideas, when you do not need to actually generate anything explicitly, instead use auto-types (like in LINQ); we can discuss it more, but I think it's doable, I've done some experiments.

3. Caching.
   Yes, caching on the client is challenging for sure. Especially that you get partial objects in queries (not all fields), and not clear how to cache it. But what I am wondering is that - as far as I understood, this caching trouble was a deal breaker for you and you decided not to go with GraphQL. Why was client cache so important? It is important for me to understand this, in order to better plan client-side support features. Maybe we can figure out something there.

thanks
Roman