DEV Community: Niek de Wit

Creating Truly Custom UI Components for AWS Cognito – Amplify in React Native

Niek de Wit — Wed, 14 Aug 2024 18:25:00 +0000

Creating Truly Custom UI Components for AWS Cognito – Amplify in React Native

AWS Cognito is a powerful tool within the AWS ecosystem, but it’s one of the most under-documented services, particularly when it comes to building custom UI components. If you’ve tried to navigate the existing documentation or blogs, you’ve likely found them confusing or incomplete, especially when you need full control over the authentication flow and user interface.

The Problem: Lack of Documentation for Custom Cognito Components
When it comes to implementing Cognito UI in React Native, the two most common approaches you’ll find are:

These options work well for standard use cases, but what if your application requires complete customization of the authentication process and UI design? Unfortunately, detailed documentation on this topic is scarce.

After spending considerable time figuring this out, I’ve developed an effective method for creating custom React Native components for Cognito. This post aims to provide a clear and practical guide to doing just that, offering an alternative to the default aws-amplify components or hosted UI.

Architecture Overview: Amplify vs. CDK
In my case, I had already set up most of my AWS infrastructure using the AWS Cloud Development Kit (CDK). During my research, I discovered that Amplify also offers tools for defining infrastructure resources, adding another layer of complexity. The challenge was finding a way to seamlessly integrate Cognito with CDK while utilizing Amplify’s frontend components/SDK—a topic that is not well-covered in existing documentation.

In this blog, I’ll walk you through setting up Cognito using CDK, connecting it to your frontend, and creating custom UI components using the Amplify SDK.

CDK Implementation: Understanding User Pools and Identity Pools
One of the most challenging concepts to grasp when working with Cognito is the difference between User Pools and Identity Pools. The official documentation says:

“User pools are for authentication. Your app users can sign in through the user pool, or federate through a third-party identity provider (IdP). Identity pools are for authorization. You can use identity pools to create unique identities for users, and give them access to other AWS services.”

While technically correct, this explanation can be a bit abstract. Here’s a simpler way to think about it:

User Pool: A database for users.
Identity Pool: A way to attach authorization policies, which can apply to one or more User Pools.

For an initial proof of concept, you’ll likely only need a User Pool. Alongside this, you’ll also need to define a User Pool Client, which acts as an endpoint accessible by the frontend. The User Pool Client has settings like whether authentication via username and password is allowed. You can create multiple User Pool Clients with different configurations, all connected to the same User Pool, depending on your use case.

Here’s how I initialize the authentication constructs in our CDK stack:

export class Authentication extends Construct {
  userPool: UserPool;

  constructor(scope: Construct, id: string, props: AuthenticationProps) {
    super(scope, id);

    this.userPool = new UserPool(this, `${props.prefix}-UserPool`, {
      selfSignUpEnabled: true,
      signInAliases: {
        email: true,
        username: false,
      },
      standardAttributes: {
        email: {
          required: true,
        },
      },
      passwordPolicy: {
        minLength: 8,
      },
      accountRecovery: AccountRecovery.EMAIL_ONLY,
      removalPolicy: RemovalPolicy.DESTROY,
      mfa: Mfa.OPTIONAL,
    });

    const userPoolClient = new UserPoolClient(this, `${props.prefix}-UserPoolClient`, {
      userPool: this.userPool,
      authFlows: {
        userPassword: true,
        userSrp: true,
      },
      generateSecret: false,
      oAuth: {
        flows: {
          authorizationCodeGrant: true,
        },
        scopes: [OAuthScope.EMAIL, OAuthScope.OPENID, OAuthScope.PROFILE],
        callbackUrls: ['http://localhost:3000'],
      },
    });

    new StringParameter(this, `${props.prefix}-CognitoConfig`, {
      parameterName: `/${props.prefix}/cognito-config`,
      description: 'Cognito configuration',
      stringValue: JSON.stringify({
        userPoolId: this.userPool.userPoolId,
        userPoolClientId: userPoolClient.userPoolClientId,
      }),
    });
  }
}

The specific configuration parameters are beyond the scope of this blog post, but you can find detailed information about them online. In the code above, we export the userPoolId and userPoolClientId to the Parameter Store for easy reference during development. This also allows us to automatically load these parameters into environment variables during the CI build process.

Configuring the Frontend
First, make the userPoolId and userPoolClientId available in your frontend. I chose to add the configuration as an environment variable, which allows us to dynamically insert this configuration during build time in CI.

AWS_COGNITO_CONFIG={"userPoolId":"eu-north-1_abc123","userPoolClientId":"abc123"}

The following code is the core of this post: an authentication service used in our frontend components. While it’s still a work in progress (e.g., it lacks proper error handling), it provides a solid starting point for building an authentication service for Cognito.

We use the aws-amplify package to initialize Amplify and combine it with functions from the @aws-amplify/auth package to interact with the Amplify SDK.

import {
  AuthSession,
  CodeDeliveryDetails,
  fetchAuthSession,
  signIn,
  confirmSignUp,
  resendSignUpCode,
  confirmResetPassword,
  signOut,
  signUp,
  resetPassword,
} from '@aws-amplify/auth';
import { signal } from '@preact/signals-react';
import { Amplify } from 'aws-amplify';
import { router } from 'expo-router';

const cognitoConfig = JSON.parse(String(process.env.AWS_COGNITO_CONFIG)) as {
  userPoolId: string;
  userPoolClientId: string;
};

export enum AuthStatus {
  SIGNED_IN,
  SIGNED_OUT,
  CONFIRM_SIGNUP,
  CONFIRM_RESET,
  LOADING,
}

export class AuthenticationService {
  $authStatus = signal(AuthStatus.LOADING);
  $authSession = signal<AuthSession | null>(null);
  $codeDeliveryDetails = signal<CodeDeliveryDetails | null>(null);

  private confirmUsername?: string;

  constructor() {
    Amplify.configure({
      Auth: {
        Cognito: {
          userPoolId: cognitoConfig.userPoolId,
          userPoolClientId: cognitoConfig.userPoolClientId,
        },
      },
    });
    this.refreshAuthState();
  }
  private async refreshAuthState() {
    this.$authStatus.value = AuthStatus.LOADING;
    const currentAuthSession = await fetchAuthSession();
    this.$authStatus.value = currentAuthSession.userSub ? AuthStatus.SIGNED_IN : AuthStatus.SIGNED_OUT;
    this.$authSession.value = currentAuthSession;
  }

  public async signIn(username: string, password: string) {
    if (this.$authStatus.value === AuthStatus.SIGNED_IN) {
      console.log('Already logged in!');
      return;
    }

    this.$authStatus.value = AuthStatus.LOADING;

    try {
      const signInResult = await signIn({
        username,
        password,
      });

      if (signInResult.isSignedIn === true) {
        await this.refreshAuthState();
        return;
      }

      if (signInResult.nextStep.signInStep === 'CONFIRM_SIGN_UP') {
        this.confirmUsername = username;
        this.resendConfirmSignupCode();
        router.replace('/auth/sign_up/verify');
      }
    } catch (e) {
      console.error(e);
      //Todo error handling/messaging
      await this.refreshAuthState();
    }
  }

  public async signUp(username: string, password: string) {
    if (this.$authStatus.value === AuthStatus.SIGNED_IN) {
      console.log('Already logged in!');
      return;
    }

    this.$authStatus.value = AuthStatus.LOADING;

    try {
      const signUpResult = await signUp({
        username,
        password,
      });

      if (signUpResult.isSignUpComplete === true) {
        await this.refreshAuthState();
        return;
      }

      if (signUpResult.nextStep.signUpStep === 'CONFIRM_SIGN_UP') {
        this.$codeDeliveryDetails.value = signUpResult.nextStep.codeDeliveryDetails;
        this.$authStatus.value = AuthStatus.CONFIRM_SIGNUP;
        this.confirmUsername = username;
        router.replace('/auth/sign_up/verify');
      }
    } catch (e) {
      console.error(e);
      //Todo error handling/messaging
      await this.refreshAuthState();
    }
  }

  public async signOut() {
    this.$authStatus.value = AuthStatus.LOADING;

    await signOut();

    await this.refreshAuthState();
  }

  public async verifySignUp(confirmationCode: string) {
    if (this.confirmUsername) {
      try {
        const confirmResult = await confirmSignUp({
          username: this.confirmUsername,
          confirmationCode,
        });
        this.confirmUsername = undefined;
        if (confirmResult.isSignUpComplete) {
          router.replace('/auth/sign_in');
        }
      } catch (e) {
        console.error(e);
        //Todo error handling/messaging
        //Dont refreshAuthState here, since this will take you away from the verification screen
      }
    }
  }

  public async resendConfirmSignupCode() {
    if (this.confirmUsername) {
      const resendCodeResult = await resendSignUpCode({ username: this.confirmUsername });
      this.$codeDeliveryDetails.value = resendCodeResult;
      this.$authStatus.value = AuthStatus.CONFIRM_SIGNUP;
    }
  }

  public async resetPassword(username: string) {
    this.$authStatus.value = AuthStatus.LOADING;
    try {
      const resetPasswordResult = await resetPassword({ username });

      if (resetPasswordResult.isPasswordReset === true) {
        await this.refreshAuthState();
        return;
      }

      if (resetPasswordResult.nextStep.resetPasswordStep === 'CONFIRM_RESET_PASSWORD_WITH_CODE') {
        this.$codeDeliveryDetails.value = resetPasswordResult.nextStep.codeDeliveryDetails;
        this.$authStatus.value = AuthStatus.CONFIRM_RESET;
        this.confirmUsername = username;
        router.replace('/auth/sign_in/forgot_password/verify');
      }
    } catch (e) {
      console.error(e);
      //Todo error handling/messaging
    }
  }

  public async verifyPasswordReset(confirmationCode: string, newPassword: string) {
    if (this.confirmUsername) {
      try {
        await confirmResetPassword({
          username: this.confirmUsername,
          newPassword,
          confirmationCode,
        });
        this.confirmUsername = undefined;
        router.replace('/auth/sign_in');
      } catch (e) {
        console.error(e);
        //Todo error handling/messaging
        //Dont refreshAuthState here, since this will take you away from the verification screen
      }
    }
  }
}

While the code may look lengthy, the concept is straightforward: we're essentially wrapping the SDK methods to expose the authentication state using Preact Signals, allowing the frontend to react accordingly. Feel free to adapt this code to suit your needs. Although Preact is specific to React, you could easily replace it with another solution to create a similar service in different architectures.

Implementing Frontend Authorization Guards
The remaining part of this blog isn't specific to Cognito/Amplify, but it might still be useful. Here’s how you could use the custom service to implement an Authorization Route Guard, which redirects users if they don't meet certain authorization/authentication checks.

import { useGlobalContext } from '@/services/global-context';
import { AuthenticationService, AuthStatus } from '@auth/authentication.service';
import { useComputed, useSignalEffect } from '@preact/signals-react';
import { router } from 'expo-router';
import { ReactElement, ReactNode } from 'react';
import { View } from 'react-native';

const AUTH_GUARD_LOADING_NAME = 'AuthorizationGuardLoading';
const AUTH_GUARD_PASSED_NAME = 'AuthorizationGuardPassed';

/** @useSignals */
const AuthorizationGuardLayoutComponent = (props: {
  guard: (auth: AuthenticationService) => string | null;
  children: (ReactElement & { type: { id: string } })[];
}) => {
  const authLoading = props.children.find((child) => child.type.id === AUTH_GUARD_LOADING_NAME);
  const authPassed = props.children.find((child) => child.type.id === AUTH_GUARD_PASSED_NAME);

  const globalContext = useGlobalContext();
  const $content = useComputed(() => {
    const authIsLoading = globalContext.authenticationService.$authStatus.value === AuthStatus.LOADING;
    const authSession = globalContext.authenticationService.$authSession.value;

    if (authIsLoading || authSession === null) {
      return 'LOADING';
    }

    const guardResult = props.guard(globalContext.authenticationService);
    if (guardResult === null) {
      return 'PASSED';
    }
    return guardResult;
  });

  useSignalEffect(() => {
    if ($content.value !== 'PASSED' && $content.value !== 'LOADING') {
      router.replace($content.value);
    }
  });

  return <View testID='authGuard'>{$content.value === 'PASSED' ? authPassed : authLoading}</View>;
};

const AuthorizationGuardLoading = (props: { children: ReactNode }) => {
  return <View testID='authGuardLoading'>{props.children}</View>;
};
AuthorizationGuardLoading.id = AUTH_GUARD_LOADING_NAME;

const AuthorizationGuardPassed = (props: { children: ReactNode }) => {
  return <View testID='authGuardPassed'>{props.children}</View>;
};
AuthorizationGuardPassed.id = AUTH_GUARD_PASSED_NAME;

This Guard component leverages the Authentication service from the global context to determine the current authentication status. If the authorization check fails, it redirects the user using the React Native Expo router; otherwise, it displays the relevant content, all managed dynamically using Preact Signals.

Using this guard might look like this;

import {
  authCheckIsLoggedOut,
  AuthorizationGuardLayoutComponent,
  AuthorizationGuardLoading,
  AuthorizationGuardPassed,
} from '@/components/layouts/route_guards/authorization_guard.layout.component';
import SignInFeatureComponent from '@features/sign_in/sign_in.feature.component';
import React from 'react';

export const SignInRouteComponent = () => {
  return (
    <AuthorizationGuardLayoutComponent guard={(auth) => (authCheckIsLoggedOut(auth) ? null : 'home')}>
      <AuthorizationGuardLoading>
        <div>checking sign in auth..</div>
      </AuthorizationGuardLoading>
      <AuthorizationGuardPassed>
        <SignInFeatureComponent />
      </AuthorizationGuardPassed>
    </AuthorizationGuardLayoutComponent>
  );
};

export default SignInRouteComponent;

Integrating the Guard
Here’s how you might integrate this guard into your feature components:

import { useGlobalContext } from '@/services/global-context';
import { Link } from 'expo-router';
import React, { useState } from 'react';
import { Button, TextInput } from 'react-native';

export const SignInFeatureComponent = () => {
  const [email, onChangeEmail] = useState<string>('');
  const [password, onChangePassword] = useState<string>('');

  const globalContext = useGlobalContext();

  const onPressSignIn = () => {
    globalContext.authenticationService.signIn(email, password);
  };

  return (
    <>
      <div>username</div>
      <TextInput
        testID='emailInput'
        onChangeText={onChangeEmail}
        textContentType='username'
        value={email}
      />
      <div>password</div>
      <TextInput
        testID='passwordInput'
        onChangeText={onChangePassword}
        textContentType='password'
        value={password}
        secureTextEntry={true}
      />
      <div>
        <Link href='/auth/sign_in/forgot_password'>Forgot your password?</Link>
      </div>
      <Button
        testID='signInButton'
        onPress={onPressSignIn}
        title='Sign In'
      />
      <div>
        <div>Need an account?</div>
        <Link
          testID='needAnAccount'
          href='/auth/sign_up'
        >
          Sign up
        </Link>
      </div>
    </>
  );
};

export default SignInFeatureComponent;

In this component, you might notice the absence of a redirect after user sign-in. This is handled automatically by the RouterGuard. For example, if the guard check for a page is defined as:

guard={(auth) => (authCheckIsLoggedOut(auth) ? null : 'home')}

The user is automatically redirected to home as soon as authCheckIsLoggedOut(auth) returns false. This check is re-evaluated every time the authentication state changes, thanks to its implementation within a useComputed Preact hook that uses the authentication state’s Preact Signals.

This post should provide a solid foundation for those looking to build truly custom UI components for AWS Cognito using Amplify in React Native. By following these steps, you’ll gain full control over both the authentication flow and the user experience, something that's not easily achievable with the out-of-the-box solutions.

Automatically Generated GraphQL Middleware Service

Niek de Wit — Wed, 14 Aug 2024 11:38:35 +0000

Automatically Generated GraphQL Middleware Service

I delved into the feasibility of creating a fully automated GraphQL middleware service. The goal was to develop a universal middleware solution that could be seamlessly adapted to various projects.

Frameworks, Packages, and Tools
• @apollo/server
• @prisma/client
• graphql
• reflect-metadata
• type-graphql
• prisma
• typegraphql-prisma

How It Works - A Quick Introduction to GraphQL
GraphQL operates on the basis of schemas that outline the structure of the data to be returned by resolver functions. Typically, when setting up a GraphQL service, a schema might be defined as follows:

type Book {
  title: String
  author: Author
}

type Author {
  name: String
  books: [Book]
}

This schema can be highly detailed, with various field types, including nullable fields, lists, and nested objects. The GraphQL server uses this schema to validate incoming queries and will return an error if the request doesn't adhere to it.
For example, a GraphQL query might look like this:

query GetBooks {
  books {
    title
    author {
      name
    }
  }
}

Based on this query, the GraphQL server identifies the necessary entities and fields to resolve. It then calls the appropriate resolver functions, which are attached to the schema.

Understanding Resolver Functions
Resolver functions are responsible for fetching and returning data in response to queries. They might be structured like this:

const resolvers = {
  Query: {
    author(parent, args, contextValue, info) {
      return authors.find((author) => author.name === args.name);
    },
  },
};

This function receives several parameters:
• parent: The return value of the previous resolver in the chain.
• args: An object containing the arguments provided for this field, such as search parameters.
• contextValue: An object shared across the entire resolver chain, often including authentication details.
• info: Provides information about the execution state of the operation, useful for logging or monitoring purposes, though less commonly used in functional logic.

TypeGraphQL
When building a "pure" GraphQL setup, maintaining the codebase can become challenging, particularly because GraphQL isn’t natively strictly typed. This is where tools like TypeGraphQL become invaluable. TypeGraphQL allows developers to define schemas, types, and resolvers in TypeScript using classes and decorators, offering a more structured and maintainable approach.

TypeGraphQL is one of the few packages that integrates seamlessly with Prisma (ORM), to automatically generate GraphQL schemas, types, and resolvers. Another similar tool is Nexus, but for this proof of concept, TypeGraphQL was the primary choice. The decision was based on its robust integration and lack of issues during implementation, so Nexus wasn’t explored further.

The beauty of this setup is that all the necessary TypeGraphQL code is auto-generated. As a result, there's no need to manually interact with or modify the TypeGraphQL code during this process.

Prisma
Prisma is a powerful ORM that, like many others, relies on a schema to describe the data structure. It simplifies database interactions by generating SQL queries from TypeScript functions and types.

One of Prisma's standout features is its ability to generate a schema directly from a connected database using the prisma db pull command. This means the data structure only needs to be defined once, in the database itself, maintaining a single source of truth.

TypeGraphQL-Prisma Integration
The integration of TypeGraphQL with Prisma is where the real magic happens. The TypeGraphQL-Prisma plugin enables the automatic generation of GraphQL schemas and resolvers based on the Prisma schema. The generated resolvers align closely with the existing Prisma API, providing full CRUD capabilities, including filtering, pagination, aggregation, and mutations, just as you would expect from Prisma.

Despite the automated generation, the plugin doesn't restrict developers to only the generated resolvers. It allows for the creation of custom resolvers, making it easy to extend the schema with additional functionality where more fine-tuned optimization is required.

To enable this feature, it's as simple as installing the necessary package and adding the following configuration to the schema.prisma file:

generator typegraphql {
  provider = "typegraphql-prisma"
  useOriginalMapping = true
}

Running the prisma generate command then triggers the plugin, which generates all the necessary TypeGraphQL classes, types, and resolvers automatically—a truly powerful and convenient feature.

Apollo GraphQL
The final piece of the puzzle is setting up a GraphQL server to serve the generated code as an API. There are various options available for this, but Apollo GraphQL was chosen due to its popularity and my familiarity with its robust features. Apollo is widely recognized in the community, making it a reliable choice for exposing the GraphQL API to a frontend application.

Implementation Middleware Service
For the most basic implementation of this proof of concept (POC), the following code demonstrates how to set up the middleware service:

// reflect-metadata import MUST be the first import.
import "reflect-metadata";
import { ApolloServer } from "@apollo/server";
import { startStandaloneServer } from "@apollo/server/standalone";
import { resolvers } from "@generated/type-graphql";
import { PrismaClient } from "@prisma/client";
import { buildSchema } from "type-graphql";
import { customAuthChecker } from "./authorization/authchecker";
import { Role } from "./authorization/role";

async function bootstrap() {
    const schema = await buildSchema({
        resolvers,
        validate: true,
        authChecker: customAuthChecker,
    });
    const prisma = new PrismaClient();
    const server = new ApolloServer({ schema });

    const { url } = await startStandaloneServer(server, {
        listen: { port: 4000 },
        context: async ({ req }) => {
        // Get the user token from the headers.
        const token = req.headers.authorization || '';
        const userRoles = await getRoles(token);
            return {
                prisma,
                userRoles,
            };
        },
    });

    console.log(`🚀 Server ready at: ${url}`);
}

bootstrap().catch(console.error);

Build Schema
The core of this implementation lies in building the GraphQLSchema object using the buildSchema method from TypeGraphQL. This schema object adheres to the GraphQL specification and serves as the bridge between TypeGraphQL and the native GraphQL ecosystem. This approach ensures that the generated schema is fully compatible with any GraphQL server, allowing for flexibility in server selection.

In the code snippet:

import { resolvers } from "@generated/type-graphql";
import { buildSchema } from "type-graphql";
import { customAuthChecker } from "./authorization/authchecker";

async function bootstrap() {
    const schema = await buildSchema({
        resolvers,
        validate: true,
        authChecker: customAuthChecker,
    });
}

The buildSchema function is where the schema is constructed, incorporating the resolvers and the custom authorization checker.
Instantiate Prisma and Apollo
After the schema is built, the next step involves instantiating key objects: the Prisma client and the Apollo server.

const prisma = new PrismaClient();
const server = new ApolloServer({ schema });

The Prisma client is particularly significant as it is auto-generated based on your database schema, ensuring that all necessary TypeScript types are available and correctly typed.

Start Server
To quickly start a GraphQL API, the startStandaloneServer function from Apollo is used. This function is ideal for POCs or simple implementations, though you could use other frameworks like NestJS, Express, or even serverless environments like AWS Lambda for production setups.

The context function is a critical part of this setup, as it provides the context object passed to the resolvers. This object can include various elements such as user roles, the Prisma client, and other relevant data.

const { url } = await startStandaloneServer(server, {
    listen: { port: 4000 },
    context: async ({ req }) => {
      // Get the user token from the headers.
      const token = req.headers.authorization || '';
      const userRoles = await getRoles(token);
        return {
            prisma,
            userRoles,
        };
    },
});

This setup allows you to define roles for the current user, which can be used in the authorization logic.

Authorization
To handle authorization effectively, TypeGraphQL-Prisma offers a robust solution that can be applied to resolvers, models, relationships, and aggregation functions. These rules must be defined before the buildSchema function is executed, ensuring they are incorporated into the schema.

Example of Applying Authorization Rules
Authorization rules can be applied as follows:

import {
    ResolversEnhanceMap,
    ModelsEnhanceMap,
    RelationResolversEnhanceMap,
    OutputTypesEnhanceMap,
    applyResolversEnhanceMap,
    applyModelsEnhanceMap,
    applyRelationResolversEnhanceMap,
    applyOutputTypesEnhanceMap
} from "@generated/typegraphql"

async function bootstrap() {
    const resolversEnhanceMap: ResolversEnhanceMap = {
        book: bookResolverAuth,
    };
    const modelsEnhanceMap: ModelsEnhanceMap = {
        book: bookModelAuth,
    };
    const relationResolversEnhanceMap: RelationResolversEnhanceMap = {
        book: bookModelRelationAuth,
    };
    const outputTypesEnhanceMap: OutputTypesEnhanceMap = {
        AggregateBook: bookAggregateAuth,
    };

    applyResolversEnhanceMap(resolversEnhanceMap);
    applyModelsEnhanceMap(modelsEnhanceMap);
    applyRelationResolversEnhanceMap(relationResolversEnhanceMap);
    applyOutputTypesEnhanceMap(outputTypesEnhanceMap);

    const schema = await buildSchema({
        resolvers,
        validate: true,
        authChecker: customAuthChecker,
    });
}

Model Authorization
An example of model-level authorization might look like this:

import { ModelConfig } from "@generated/type-graphql";
import { Authorized } from "type-graphql";
import { Role } from "../role";

export const bookModelAuth: ModelConfig<"Book"> = {
    fields: {
        _all: [Authorized(Role.USER)], // default for all fields
        title: () => [Authorized(Role.ADMIN)], // override for specific field

      /** Override default
        * the function variant overrides the default, but takes the default as a parameter,
        * so you can leverage that to combine the _all and selected method decorators in a desired way
        */
      summary: (defaultRoles) => [...defaultRoles, Role.Admin]
    },
};

Relation Authorization
An example of relation-level authorization might look like this:

import { RelationResolverActionsConfig } from "@generated/type-graphql";
import { Authorized } from "type-graphql";
import { Role } from "../role";

export const bookModelRelationAuth: RelationResolverActionsConfig<"Book"> = {
    _all: [Authorized(Role.USER)], // default for all relations
    book_author: () => [Authorized(Role.USER)]
};

Aggregation Authorization
An example of aggregation-level authorization (over an entire entity more generally) might look like this:

import { OutputTypeConfig } from "@generated/type-graphql";
import { Authorized } from "type-graphql";
import { Role } from "../role";

export const bookAggregateAuth: OutputTypeConfig<"AggregateBook"> = {
    _all: [Authorized(Role.USER)], // default for all aggregations
    _count: () => [Authorized(Role.ADMIN)],
    //_avg: (defaultRoles) => [],
    //_sum: (defaultRoles) => [],
    //_min: (defaultRoles) => [],
    //_max: (defaultRoles) => [],
};

An example of aggregation-level authorization (on specific entity fields) might look like this:

import { OutputTypeConfig } from "@generated/type-graphql";
import { Authorized } from "type-graphql";
import { Role } from "../role";

export const bookAvgAuth: OutputTypeConfig<"BookAvgAggregate"> = {
    _all: [Authorized(Role.USER)], // default for all aggregations
    word_count: () => [Authorized(Role.ADMIN)],
};
//Other types of aggregations to possibly write authorization rules for:
//bookAvgAggregate
//bookCount
//bookCountAggregate
//bookGroupBy
//bookMaxAggregate
//bookMinAggregate
//bookSumAggregate

Resolver Authorization
For resolvers, you can define authorization rules like this:

import { ResolverActionsConfig } from "@generated/type-graphql";
import { Authorized } from "type-graphql";
import { Role } from "../role";

export const bookResolverAuth: ResolverActionsConfig<"Book"> = {
    _all: [Authorized(Role.USER)], // default for all resolvers
    createManyBook: () => [Authorized(Role.ADMIN)], // specific resolver rule
    createOneBook: () => [Authorized("CONDITIONAL_BOOK_TYPE")], // conditional authorization
};

Conditional Authorization
Conditional authorization adds another layer of security by basing permissions on the input data for a mutation. For example, you might want to restrict certain actions to specific roles based on the value of a field in the input:

export const conditionalCreateOneBookAuth: Partial<Record<string, (args: { data: BookCreateInput }) => Role[]>> = {
    CONDITIONAL_BOOK_TYPE: (args: { data: BookCreateInput }) => {
        const input = args?.data;
        if (input.type === "protected") {
            return [Role.ADMIN];
        }
        if (input.type === "public") {
            return [Role.USER];
        }
        return [];
    },
};

Custom Authorization Checker
The custom authorization checker evaluates whether the current context meets the authorization requirements defined for each resolver, model, field, relation, or aggregation:

cosnt conditionalAuth: Partial<Record<string, (args: any) => Role[]>> = {
    ...conditionalCreateOneBookAuth
}

export const customAuthChecker: AuthChecker<{ userRoles: Role[] }> = ({ context, args }, authRoles) => {
    const conditionalRole = authRoles.find((role) => !!conditionalAuth[role]);
    if (conditionalRole) {
        authRoles = (conditionalAuth[conditionalRole]?.(args) || []) as string[];
    }

    if (authRoles.length === 0) {
        return false;
    }

    const authenticated = authRoles.some((authRole) => context.userRoles.includes(authRole as Role));

    return authenticated;
};

This customAuthChecker is used during initialization of the setup:

const schema = await buildSchema({
    resolvers,
    validate: true,
    authChecker: customAuthChecker,
});

This implementation ensures that roles are checked against both static and dynamic conditions, providing robust security tailored to your application's needs.

Pros & Cons of the Approach

Pros:
1. Schema Synchronization: The middleware setup ensures the database and API schema remain in sync automatically, minimizing manual intervention and reducing the potential for discrepancies. Only the authorization rules would have to be maintained.
2. Future proof: The generated resolvers seem to cover pretty much all needs for any standard frontend you might develop. While keeping the option to implement custom resolvers within the same development paradigm.
3. Flexible and Efficient Data Fetching: GraphQL allows clients to request only the data they need, avoiding over-fetching. This not only optimizes payload sizes but also reduces the number of network requests, leading to better performance.
4. Single API Endpoint: By using GraphQL, all data operations are consolidated under a single endpoint, simplifying the API structure and reducing complexity in managing multiple endpoints.
5. Ease of Understanding with GraphiQL: The schema-based nature of GraphQL, along with tools like GraphiQL, makes it easier for developers to explore and understand the API, thus improving developer experience.
6. Incremental Evolution of Schema: Fields can be added or modified in the schema without impacting clients that do not use those fields, allowing for smoother API evolution.
7. Rich Ecosystem: The GraphQL ecosystem is robust, with numerous tools and libraries available across various platforms, aiding in faster development and integration.

Cons:
1. Potential Complexity: Implementing and maintaining GraphQL servers can become complex, especially with custom data resolvers for different scenarios. While TypeGraphQL-Prisma abstracts some of this complexity, there’s a risk of encountering issues in auto-generated resolvers, which might be challenging to fix.
2. Caching Challenges: Unlike REST, where caching is more straightforward due to predictable endpoints, caching in GraphQL can be more complicated. Each query is unique, making traditional caching mechanisms less effective.
3. Performance Concerns: Complex and overly nested queries or inefficient resolvers can impact server performance. It could be that the generated TypeGraphQL resolvers do something smart for this issue. For example to use the dataloader pattern. However, I have not had the opportunity yet to investigate this topic.
4. Adoption and Skill Gap: Despite its growing popularity, GraphQL is still not as widely adopted as REST. This might present a learning curve for teams unfamiliar with the technology.
5. Security Considerations: With GraphQL’s single endpoint, securing the API becomes more complex. Fine-grained control over authorization at the resolver, model, and field levels is necessary, making it more challenging compared to REST.

Todo
While the POC has demonstrated the potential of this stack, several areas require further exploration to fully assess its viability for production use:

Automated Deployment Pipeline: Investigate the possibility of setting up an automated CI/CD pipeline that:
- Triggers schema generation (prisma db pull) and resolver generation (prisma generate) on database changes.
- Automates the addition or removal of authorization rules, creating a PR for review.
- Deploys the updated middleware upon PR merge.
Explore Nexus as an Alternative: Nexus could be a viable alternative to TypeGraphQL for generating resolvers and schema. Evaluating its performance and ease of use compared to TypeGraphQL is worth considering.
Performance Testing: Conduct performance tests with large and complex GraphQL queries to identify any potential issues with the N+1 problem. This might involve examining whether the generated resolvers use optimizations like the dataloader pattern.