From 9b4110558affd86c38388499f7631b97d8356f07 Mon Sep 17 00:00:00 2001 From: Jonathan Eatherly Date: Mon, 10 Feb 2025 12:20:57 -0600 Subject: [PATCH] Minor doc typo fix in authorization.mdx --- src/pages/learn/authorization.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/learn/authorization.mdx b/src/pages/learn/authorization.mdx index da91da0089..f23fab82ef 100644 --- a/src/pages/learn/authorization.mdx +++ b/src/pages/learn/authorization.mdx @@ -33,7 +33,7 @@ function Post_body(obj, args, context, info) { } ``` -Notice that we define "author owns a post" by checking whether the post's `authorId` field equals the current user’s `id`. Can you spot the problem? We would need to duplicate this code for each entry point into the service. Then if the authorization logic is not kept perfectly in sync, users could see different data depending on which API they use. Yikes! We can avoid that by having a [single source of truth](/learn/thinking-in-graphs/#business-logic-layer) for authorization, instead of putting it the GraphQL layer. +Notice that we define "author owns a post" by checking whether the post's `authorId` field equals the current user’s `id`. Can you spot the problem? We would need to duplicate this code for each entry point into the service. Then if the authorization logic is not kept perfectly in sync, users could see different data depending on which API they use. Yikes! We can avoid that by having a [single source of truth](/learn/thinking-in-graphs/#business-logic-layer) for authorization, instead of putting it in the GraphQL layer. Defining authorization logic inside the resolver is fine when learning GraphQL or prototyping. However, for a production codebase, delegate authorization logic to the business logic layer. Here’s an example of how authorization of the `Post` type's fields could be implemented separately: