Replies: 7 comments 14 replies
-
|
Hi @rivantsov ! Thanks for your feedback. It's much appreciated. I think you're correct that semantic information is derivable by humans from API docs and field names, so I won't spend too much time addressing that. However, I want to clarify that the Client Controlled Nullability (CCN) proposal does not affect SDL. The syntax introduced by the proposal is solely used by developers writing operations.
While I think there is some human-readable semantic information provided by CCN, I don't think operations are read nearly as much as SDL (and API documentation) so I don't think it's nearly as important as what it enables for tooling. That's why that was the primary focus of the original RFC, so I'm glad you included a section about tooling. I realized I didn't have the original RFC linked in the spec PR, so I've fixed that. Here's a link so you can read more about the motivations behind the proposal: https://github.com/graphql/graphql-wg/blob/main/rfcs/ClientControlledNullability.md The TL;DR relevant to you is that at Yelp, code generation was rendered practically useless. Developers needed to write wrapper types for every operation to handle all of the null-checking that was required. The Relay team saw similar problems at the company formerly known as Facebook, so they introduced a Relay-specific version of CCN before we even started talking about CCN. If you think those motivations aren't clearly translated over to the spec, let me know and I'll see what I can do to fix that :) I've got some questions about the use case you described in "4. Static constraints are overrated IMO", but I'll have to come back to that later today. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for reply. Pls note that I intended these comments to be about 2 RFCs - CCN and Named Lists. So some of them, apply more to one than to other. I will read the links you provided and maybe will have some more to say. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, clearing the context that "It's all for client generators" - that changes the perspective. While I was listening to meeting recording, it all sounded like it's for human consumption. So my 'utility evaluation' ideas probably do not apply that much to CCN. But then I have more questions, and even doubts.
but I think you should add this, for clarity. Otherwise it sounds like both markers are equal in their function and independent of each other.
The client sends a request with ! on some nullable field. The server executes and ends up with null value for the field. The server then returns null for the field (it is nullable in schema!), but also adds an error to the response, with the path to the field. The client upon receiving response sees the error. So it needs to do the '?' part, nullify the containing object. I think it is not very complicated - take 'data' element, load into js object, follow the path of error (cut the last segment) and nullify it (parent object). Upon completion of all errors, the data object is serialized to json - and here you have it, the action of '?' done on the client. Then you can load this json into your data model. Again, not a js programmer, but - does this sound like something that can be done? If yes, then we can go with just ! modifier. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, if I understand the flow correctly, a client side non-null causes the parent field completion to throw and therefore to appropriately quit working on any additional sibling fields. This is true in graphql-js even for async fields (although not in graphql-executor, see graphql/graphql-js#2974 and yaacovCR/graphql-js#33) A client side non-null can therefore be thought of as a client side execution instruction similar to skip/include, directing the flow of execution. It’s not necessarily something the client can do herself. |
Beta Was this translation helpful? Give feedback.
-
|
Although I don’t agree with the basic premise here, and agree with @twof response, the whole idea of non null fields are to offer null protection for clients, which is a convenience that the server offers in graphql. As of now, fields are null protected when defined as such within the schema on the server, and the idea of this PR is to allow clients to specify what null protection they want. It’s not really “extra” work, and it’s the same type of “extra” work that we already do, just doing it when actually necessary for the client… |
Beta Was this translation helpful? Give feedback.
-
|
I do not think analogy with skip/include works here, it is not the same. For skip, the goal is to reduce network traffic; the client can perfectly do it (throw away data), but it is waste of network resources, so asking server to filter it out makes sense. For '!' - there's no such excuse, it is simply loading work on server, work that can be done by client. On another subject
I would be probably ok with '!', but I feel against '?', it looks really confusing and unintuitive, and it is in fact ask to server to violate the contract (schema) |
Beta Was this translation helpful? Give feedback.
-
|
@rivantsov We've discussed having a non-destructive alternative like you're suggesting (no change to
What did you mean by this? I'd also like to question the notion that propagating null to parent fields will be an undue burden on servers. If that were the case, I'd expect to hear that it's best practice to mark all fields nullable because doing otherwise causes a substantial performance hit. I've yet to hear anyone suggest that. If performance is a legitimate concern, however, we could consider adding performance tests to the GraphQL-JS implementation, but I think @yaacovCR is correct that the time potentially saved by not resolving, encoding, and transferring sibling fields is far far greater than the hit from a null propagation. Even if the performance was worse, we'd be trading developer time for CPU time, and developer time is very nearly always more valuable. |
Beta Was this translation helpful? Give feedback.
-
|
Ok man, you lost me. I do not get the logic at all. Let me go thru it step by step. What common client ? (you ask) - I meant that code like that can be either added to a JavaScript component that you use for sending/receiving GraphQL (like Apollo or Relay clients), or hook to processing event of client component. I assume that there's some place to put this code for the entire client app, that's it. In your first response on this thread, you explained that this feature will benefit code generators, here is quote:
Your link to Relay compiler brings a post with examples of code with and without @required directive. Ok, I understand this, looks like legit case. But... GraphQL spec is not a Santa's list, all good kids get whatever they want there. Only features are absolutely necessary, that have no reasonably easy workarounds - I hope you agree with that. You: We need CCN that's what is looks like so far to me. You presented problem for client code generators, we found a solution, no need to add anything to spec so far.
- nobody dictates anything! you had a problem, we found a solution, without changing the spec. Use it if you want to.
should they? did they actually have problems? it was code generators for Relay who needed solution. Am I missing something?! As for 'unique burden on the server". I do not say it will overload and crash servers, of course not. It's just feels the outcome of CCN is transferring some activity to Server, using some confusing syntax (it will be confusing and will require quite detail explanations with several sample scenarios); if will not crash the server, but as a server-side guy, I would prefer it the other way; move CPU work from server to client. |
Beta Was this translation helpful? Give feedback.
-
Haha! 😻
|
Beta Was this translation helpful? Give feedback.
-
You can encode that in GraphQL: interface Document {
id: ID!
title: String
body: String
# ...
}
type DraftDocument implements Document {
id: ID!
title: String
body: String
# ...
}
type PublishedDocument implements Document {
id: ID!
title: String!
body: String!
# ...
}There's been some discussion over the years about adding literal values (e.g.
You can encode that in the database with check constraints: create table documents (
id int primary key,
title text,
body text,
status text not null,
check (status <> 'PUBLISHED' or (body is not null and status is not null))
);This is, however, hard to extract meaning from programatically - you either need a human to interpret it or some complex code. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the response But the main problem with constraints like this - these are 'biz logic' rules. Which means they come from business/life. Which means they change. Get extended. And exceptions or special cases show up. Even if you succeed in encoding some flexible constraint, then pushed and made a Release - as soon as you're done, a biz-analyst/PM/customer shows up - "Ok, we need one special case, for this new (contract/invoice/ins-policy) doc type, this X might be null, and this Y is never null." You have no power to say NO, it is business, that's how the process works in real world, and you have to change it, ASAP. It is a constant stream of changes and exceptions from rule, and a 'static' constraint is NOT a good way to express it. I know how to make database constraints, I spent a lot of time in relational databases. But if we learned anything in the last 20 years it is this: do NOT put biz logic into database, ever. Because logic will be changing non-stop and it will become nightmare to maintain and re-deploy. And the sample conditional non-null constraint is biz logic, it comes from business. The same reasoning applies to your example in GraphQL. Expressing it in GraphQL - cool! but not actually helpful in real life, by the same reasoning as with databases. And looks to me the solution makes the model quite bloated, with extra type for each doc status. Introducing new status would require an extra type. The net conclusion again - Static type constraints are overrated. Not useless, but not as useful as it might seem. It's not worth inventing ways to express more complex type constraints, they won't be used much; just like fancy constraints in modern databases. PS Remember Eiffel progr language? the primary idea was contracts, static constraints, compile time validation. Did not work out. Life is too complex and changes too much to be put into static contracts. |
Beta Was this translation helpful? Give feedback.
-
|
Edit: changed 'static typing is overrated' to 'static type constraints are overrated', that expresses it better |
Beta Was this translation helpful? Give feedback.
-
Topic: Named ListsThanks for opening the discussion. There are some points I agree with, but I differ on some. Documentation
First of all, I don't think the restriction of the types behind the fields is always so obvious. For the invoice, this may be clear, but there are cases where it is not. Hypothetically, what if I never heard what the invoice is? (I know it's not realistic for the invoice, but it may make sense for another term in some domain). Plain documentation vs Types as documentation
Yes, that is correct. But types are also a way of documentation. The tedious thing about field documentation is its maintenance. When I update a certain behavior of invoices (e.g size), I have to simultaneously update the description of each field associated with the invoice in multiple parts. However we could define a list type with the name "Invoices" and its description, which we use for each field where we use invoices. this way we can also provide a description for all these fields. """
some specific behaviour for invoices
"""
list InvoicesDocumentation can't be type-checked
However, the documents cannot be used by GraphQL client and server tools for static constraint checking ( as discussed in Chapter 3.). Static constraints are not overrated
I see it a different way. As developers, we want to ensure that errors we can avoid at compile time are handled by the type system, not by us. Ideally, the program is a formal proof of our requirements (see Curry-Howard correspondence). However, if we specify an incorrect formula, our program will give the false impression of proof of correctness. In other words, our application will crash at some point in the runtime (in the worst case, in production).
In your example, I see that documents with the status "DRAFT" and "PUBLISHED" have different characteristics and should not be unified as one type instead of having two different types as @benjie represented. Use cases and Client benefits
First, this feature is beneficial not only for the clients but also for the servers since the named list automatically validates all list values that the server sends to the client. Second, some common types like ( |
Beta Was this translation helpful? Give feedback.
-
|
Documentation
In any domain, you should know something about domain area, if you are doing UI or a client for a GraphQL API. But in any case, I do not mean semantics always give you all and you do not look at type constraints. But very often the semantics, the meaning helps, especially with complex constraints. And thus the extra benefit of constraints or extra types like Set or NonEmpty list is diminished. We are in cost/benefit analysis here. Documentation maintenance
You can do exactly this today, with a Type with a single list field: type Invoices {
I assume you think of a scenario like this. On a server, there is some Response Verifier method that sits on the output of the server and verifies every response before it is sent to client. It verifies the constraints from API Schema like notNull for fields. Well, as a server programmer, I can tell you - there is no such thing. For two reasons:
Hence auto-verifier is useless. At least on the server. If you need verifier to catch null values on non-null fields, then there is something really wrong with your code. You'd better fix it, instead of looking for verifiers. Not sure about clients, running verifier of request; but it seems useless too. If you send invalid request, you will get error from server. What's the difference with client side verifier error? Nothing. As long as you're not sending too many bad requests, you're fine, and server will return errors for you. Tools like Graphiql. Well maybe they can show some squiggly line in some place, to indicate constraint violation, but that's all. If I write invalid request and click execute, Graphiql or any other tool will execute it - and it should! Simply because tool's validation code should never override user's decision about Curry-Howard and stuff - to be continued |
Beta Was this translation helpful? Give feedback.
-
|
I have posted a feedback on original NamedLists thread: |
Beta Was this translation helpful? Give feedback.
-
|
About proof of correctness and Haskell and all that stuff.
well... here comes again, the dream of a magic verifier of correctness. And you mentioned Haskell. https://jaxenter.com/disadvantages-of-purely-functional-programming-126776.html in the post, the link about quick sort is dead, but here is an updated URL: So, please read the quick sort story in Haskell. Multiple attempts by PhD's, experts in Haskell, several years... and multiple failures, published code contained bugs. Quick sort, not a super-high math. My question - where were the correctness verifiers-proofers. Wasn't Haskell created for this kind of stuff? With all the advance nature of Haskell type system, why couldn't they quickly produce correct code?! What I am saying is this. Practical programming of real life systems and this Curry-Howard academic stuff - these are 2 complete separate universes. All this proof of correctness theoretical stuff simply DOES NOT WORK in real life. Useless. Tried and failed many times. So let's leave it alone, all these proofers and hopes that advanced enough type system (a-la category theory?!) will save us all some day. Also, let's remember: GraphQL is not a programming language. It is a language to express queries and (relatively simple) data manipulation instructions, from client to server. Not for coding complex algorithms. So analogies with programming languages - might work but to a very limited extent. My main line again: inventing more complex type system has limited benefit in GraphQL. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reply :) I am sorry if my response left a different impression than I intended. I have no illusions that the type system will eliminate all possible bugs. However, if it eliminates about 95% of them, we can deal with the last 5%. Besides, the problem described in the article was quite interesting in terms of performance and memory issues. However, it is not completely relevant as a counterargument for the type system, since the problem is caused by the pure nature of the language, but not by the complexity of the Haskell type system. Besides, if fewer types are better suited for real-world use cases, then it's hard to explain why most people prefer Typescript (i.e. in GraphQL.js) over JS. Haskell handles side effects with monadic IO functions. These monadic functions cannot guarantee execution safety any more than procedural or OOP language. Therefore, classical mutation errors may occur at runtime. Since the type system can only guarantee that if we expect apples, we will not get oranges at runtime. Besides, the use of a language always depends on the domain. Therefore, evaluating the uselessness of a language is not an obvious question. Although there is an opinion that Haskell can be useless in real life. In the last decades, more and more companies have used Haskell to solve their domain-specific problems. The examples that immediately come to mind are Haxl and Cardano. GraphQL is not a programming language, however, it gives us guidelines for modeling applications that use it. Therefore, the absence of specific features in the type system implies limitations in the target language. |
Beta Was this translation helpful? Give feedback.
-
|
Well, you brought up this stuff, quote: " Ideally, the program is a formal proof of our requirements (see Curry-Howard correspondence)." |
Beta Was this translation helpful? Give feedback.
-
|
Alright :) Please note that I started the sentence with the word "Ideally". Nothing is ideal in the real world of programming, but we always have to deal with some kind of trade-offs. however, that doesn't mean we shouldn't try to achieve it to some degree. also, let's not forget that Haskell is a programming language, not a proof assistant. Haskell guarantees a high level of safety (but still not 100%) when writing pure code. if we violate this (which is what happened in the article), we are almost working with a regular language and the "correctness proof" is pretty irrelevant that case. Yes. I also think we should get back to the original topic of |
Beta Was this translation helpful? Give feedback.
-
Comments on some discussions at WG meeting on Jan 6 2022
Benjie - what a gorgeous CAT you have there! Too bad it looked like he didn't want to contribute, not a single 'meow' :).
My comments concern discussions of 2 items: 'Named Lists' and 'Client controlled nullability'. Costs/benefits analysis for expressing extra type constraints like list elements nullability. I absolutely agree that we must evaluate potential utility against added complexity. What I am concerned with is how we approach this benefits evaluation.
It seems to me, after listening and reading arguments, that we kinda assume that for an API the SDL schema doc (or introspection) is the ONLY information that will be provided to the consumer (human developer), so we need to express as much details as possible like nullability of elements deep inside multi-level lists. So the typical scenario is like this: the client programmer looks at schema doc, and starts programming the client based on what he/she sees in the doc. Thus the schema doc must provide as much details as possible about the types and fields and possible list contents, so there must be a syntax to express these extra constraints.
However, I think we are making a mistake here, and as a result the utility/usefulness of a feature is overrated.
1. Semantics of the types/model express natural constraints
The real world types and fields are NOT meaningless foos/bars, they have explicit real-world semantics which make natural constraints clear and obvious in most cases. If we have an Invoice Type with Items list property, it is clear that this list cannot contain nulls, it does not make sense. On the other hand, if I have tic-tac-toe board represented as 2-dim array:
then it is clear that individual cells are nullable, and all nulls is initial board. I am not saying that exact nullability notation is useless, but that its utility is limited, it just confirms what is already clear from semantics.
The same goes for other constraints like suggested in 'NamedLists', for ex (quote): "we cannot represent collections with certain constraints."; like "list contains at least 1 element". For an Invoice type as an example, it does not make sense to have invoice with 0 items. Thus 'non-empty' constraint is clearly derived from type semantics. The extra syntax expressing this non-empty constraint just confirms what is clear already.
2. There is always documentation for non-trivial API which describes semantics and constraints
Any non-trivial API is delivered with documentation that describes the SEMANTICS of the API and its business semantics that is not expressible in syntax in the schema doc. Even if this documentation is only in extended description fields in the schema. It is these docs that contain all detail information about types and restrictions and validation rules for the data types and fields, in context of 'business flow'. And these docs should contain clear info on list like Invoice.Items - can it be null or can contain zero items. It is not my wishful thinking that there must be docs - for non-trivial API the semantics and flows should be described somewhere, otherwise it is not possible to use the API.
3. Tools may benefit?
So these 2 factors (semantics and extra API docs) make the utility (value added) of extra syntax for constraints quite limited and marginal in most cases, specifically for humans (devs) that can understand model semantics and can read docs. However, there is another type of information users - TOOLS, that cannot read plain docs and don't understand semantics of the API, they use introspection only. Can they use extra type constraint info?
During discussion of the features, there came a suggestion to find real world cases (lists specifically of higher ranks) to evaluate the potential benefits. What I suggest here, given the limited utility of the constraints for human developers (that I argued previously), we should instead look at tools like Graphiql and client generators, and ask a question - how it will benefit them, and indirectly humans that use them? Looking at tools is simpler I think than hunting for real world uses of some list types.
And here I have doubts - that these constraints will benefit the tools, but I might be wrong.
4. Static constraints are overrated IMO
One more general consideration. In general, I think static type constraints (like null/nonNull) are overrated, and their possible impact on bugs in programming languages. There is wide-spread belief that since many of runtime bugs are NullReferenceException, then if we tighten the control of null values, and add static constraints on fields and variables that value may not be null then we'll reduce number of these bugs. This is the reasoning behind recent introduction of new c# features of 'non-nullable reference types'.
In my opinion, this is a false hope.
The problem is - in many business cases the nullability of a field depends on the containing document 'Status'. A document (entity, complex type instance) goes thru a lifecycle; at the end, the document like Invoice MUST have certain fields nonNull - but only when it is in some final state like 'Approved'. Initially, however, it starts life in a Draft state, when many of the fields are null or empty lists, and it goes thru the process of filling things out. As a result, we CANNOT enforce a static constraint like NonNull on many fields, because they are NULL initially.
The same goes for many other constraints. And many 'nullability' constraints depend on the invoice 'kind' or sub-type; there are many kinds, and each has it's own validation requirements.
Added: the conundrum becomes very apparent when you design database table for Invoice and alike doc entities. You have to make many columns nullable even if it does not make sense for biz. It is in fact frustrating to see that you CANNOT use non-null constraint and have database assist you in validation/consistency - just because the doc starts in some DRAFT state for some short time where things can be null.
From my experience, this is very common case, and it is THESE fields that are nullable initially, but should be assigned later, are the cause of NullReferenceExceptions down the road. These are real hard cases and hard bugs - the process expects Address to be filled but it's not. And static NonNull constraint cannot help, it cannot be used here.
So what I am saying - don't sweat over expressing precise constraints on fields and values, they are NOT so useful after all. This is from my 25 years of experience in the industry, I cannot bring up exact numbers obviously.
So to sum it up - if take all these considerations into account, the cost/benefit ratio of the features like 'NamedLists', or exact nullability of nested lists is quite LOW, at least it appears to me, given really non-trivial and potentially confusing syntax
thank you
Beta Was this translation helpful? Give feedback.
All reactions