From cbf331e3ed47a9cc715308d9ee24ab4d263b4990 Mon Sep 17 00:00:00 2001 From: Ivaylo Kirov Date: Mon, 27 May 2019 16:34:42 -0400 Subject: [PATCH 1/2] Update BestPractice-Introduction.md --- site/learn/BestPractice-Introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/learn/BestPractice-Introduction.md b/site/learn/BestPractice-Introduction.md index b86e7e93d9..2b55b65c3a 100644 --- a/site/learn/BestPractice-Introduction.md +++ b/site/learn/BestPractice-Introduction.md @@ -45,7 +45,7 @@ In contrast, GraphQL only returns the data that's explicitly requested, so new c ### Nullability -Most type systems which recognise "null" provide both the common type, and the *nullable* version of that type, whereby default types do not include "null" unless explicitly declared. However in a GraphQL type system, every field is *nullable* by default. This is because there are many things which can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules. +Most type systems which recognise "null" provide both the common type, and the *nullable* version of that type, whereby default types do not include "null" unless explicitly declared. However, in a GraphQL type system, every field is *nullable* by default. This is because there are many things which can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules. By defaulting every field to *nullable*, any of these reasons may result in just that field returned "null" rather than having a complete failure for the request. Instead, GraphQL provides [non-null](/learn/schema/#lists-and-non-null) variants of types which make a guarantee to clients that if requested, the field will never return "null". Instead, if an error occurs, the previous parent field will be "null" instead. From e65b5acd7fe08e0940bf348442670257d30c4d8c Mon Sep 17 00:00:00 2001 From: Ivan Goncharov Date: Fri, 28 Aug 2020 17:02:32 +0300 Subject: [PATCH 2/2] Update site/learn/BestPractice-Introduction.md Co-authored-by: Carolyn Stransky --- site/learn/BestPractice-Introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/learn/BestPractice-Introduction.md b/site/learn/BestPractice-Introduction.md index 2b55b65c3a..c98cf6f052 100644 --- a/site/learn/BestPractice-Introduction.md +++ b/site/learn/BestPractice-Introduction.md @@ -45,7 +45,7 @@ In contrast, GraphQL only returns the data that's explicitly requested, so new c ### Nullability -Most type systems which recognise "null" provide both the common type, and the *nullable* version of that type, whereby default types do not include "null" unless explicitly declared. However, in a GraphQL type system, every field is *nullable* by default. This is because there are many things which can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules. +Most type systems which recognise "null" provide both the common type and the *nullable* version of that type, whereby default types do not include "null" unless explicitly declared. However, in a GraphQL type system, every field is *nullable* by default. This is because there are many things that can go awry in a networked service backed by databases and other services. A database could go down, an asynchronous action could fail, an exception could be thrown. Beyond simply system failures, authorization can often be granular, where individual fields within a request can have different authorization rules. By defaulting every field to *nullable*, any of these reasons may result in just that field returned "null" rather than having a complete failure for the request. Instead, GraphQL provides [non-null](/learn/schema/#lists-and-non-null) variants of types which make a guarantee to clients that if requested, the field will never return "null". Instead, if an error occurs, the previous parent field will be "null" instead.