Forem: Thomas Maximini

Typescript: Bang operator considered harmful

Thomas Maximini — Thu, 03 Dec 2020 13:15:54 +0000

We recently ran into a few runtime errors in our frontend. People would get errors like Cannot read property x of null or Cannot read property .length of undefined and so on. Something propably every Javascript developer has encountered before.

no bueno!

But our codebase is a Next.js application written in Typescript. How did the Typescript compiler not catch those errors during compile time.

Digging a bit deeper, I found that we had a rule in our .eslintrc that turned off any warnings around using the bang(!) operator in Typescript:



// .eslintrc
rules: {
// ...
'@typescript-eslint/no-non-null-assertion': 'off'
}

The Typescript docs define this as the non-null-assertion operator. The docs state

A new ! post-fix expression operator may be used to assert that its operand is non-null and non-undefined in contexts where the type checker is unable to conclude that fact. Specifically, the operation x! produces a value of the type of x with null and undefined excluded. Similar to type assertions of the forms x and x as T, the ! non-null assertion operator is simply removed in the emitted JavaScript code.

Sounds difficult. But all it does is basically telling the compiler "this value can not be null or undefined".

One of the great advantages of Typescript is that it checks your code instantly for any type errors (duh), so whenever you are working with an object or variable value that might be undefined, it gives you a warning.

It usually does so by underlining the variable and showing you a little warning. The lazy developer might just go ahead, yell at Typescript that they know what they're doing and add a ! to it. Problem solved right?

This might cause the compiler to shut up, but then lead to the undesired runtime errors we saw above. It might be defined 99% of the time or even 100% of the time on your local machine. Especially when working with asynchronous code, such as GraphQL queries and mutations, it's important to know that objects and values can often be undefined. Maybe the data is still being loaded or something takes a while until it is initialized.

The problem is that these exclamation marks are difficult to miss in a code review. Maybe someone started using them, they end up in the codebase. The next pages are partly copied and pasted or newer developers see this and start copying the pattern. Suddenly you have exclamation marks all over your codebase because it seems to make Typescript happy.

A better alternative would be using the optional chaining ? operator that got introduced in Typescript 3.7.

And for React components, you can use the logical AND && operator:



// wrong
<VideoPresentation videoPresentation={videoPresentation!} />
// better
{videoPresentation && <VideoPresentation videoPresentation={videoPresentation} />}

By setting the eslint rule correctly to '@typescript-eslint/no-non-null-assertion': 'error' we've now disallowed any usage of that operator. In my opinion it defeats the purpose of Typescript, which brings a lot of sanity and safety into bigger Javascript projects.

Do you agree or do you think there are valid use cases for the ! operator in Typescript. Let me know at Twitter.

Photo by Cindy Tang on Unsplash.

This post was originally published on My personal blog.

Authentication in Next.js apps

Thomas Maximini — Tue, 24 Nov 2020 16:05:23 +0000

I love Next.js.

Whenever I build production-grade websites with React, I will choose Next.js as the go-to framework.
What makes it an exceptional choice for me is that it abstracts away all the time-consuming gruntwork, such as server-side rendering (SSR),
Webpack and Typescript configurations, routing and so on for us, so we can work on our actual unique features instead of wasting time on these Metatasks.
And it does all of them very well, better as most people trying to implement these things themselves. I would advise strongly against trying to build your own server rendered React app in 2020, unless you are some kind of masochistic psychopath.

Next.js 10

Next.js just keeps getting better. The recently released version 10 with tons of improvements.
It's awesome. The have now a next/image helper similar to what Gatsby does with Gatsby image, support for i18n routing by default, and many other goodies. Head over there and check the changelog if you haven't already.
But this post is about authentication, so let's dive into that!

Authentication in Next.js

There is no one way on how to deal with authentication in Next.js.
Ideally you don't try to re-invent the wheel and go with one of the standard auth providers, such as Firebase, Auth0 or Cognito.
You'll find examples on how to use those in the Next.js Github repository.
We use Firebase authentication over at Crowdcast, but those are all valid choices.
There is also a relatively new project called next-auth which we tested briefly and which looks very promising. This should cover most of the needs for authentication in Next.js apps.

How to structure your authentication

The first thing I like to do is seperating my pages into three categories:

Pages that everyone can view (public)
These pages don't need any authentication
Pages that are absolutely unaccessible when a user is not authorized. These pages are usually good candidates for server-side authentication.
Pages and components that show differet views depending on a user's state. These pages are usually good candidates for client-side authentication.

Let's look into the last two in more detail:

Server-side authentication

Imagine you have some sensitive user data on your site such as a user's personal E-Mail and their payment information. This data can be accessed on the /account page. Now, when a user is not logged in, it does not make sense to render anything on this page at all, instead we want to redirect them to /login.
So we want to use a server-side authentication here. That means, we check on the server if a user is logged in, and if not, we redirect them using an HTTP redirect. If they are logged in, we pass their user data directly into our Account page, so we can start rendering immediately and save another round trip.
For this, we make use of a method called getServerSideProps (docs). This was introduced in Next.js version 9.3, before that it was called getInitialProps.
One thing to note is that this function has to exported seperately from a next.js page. This means, we can not use a higher-order component and wrap all the pages that use server-side auth with it, but we have to export it from each page.

The logic of that function depends on your use case. In my example it it is fairly straightforward: We try to read a user object from the session object that is stored on the request. If the user is found, return it as a prop to the page, if not, redirect the user to the /login route.

export const getServerSideProps = ({ req, res }) => {
  try {
    const user = req.session.get('user');
    if (!user) throw new Error('unauthorized');

    return {
      props: {
        user,
      },
    };
  } catch (err) {
    return {
      redirect: {
        permanent: false,
        destination: '/login',
      },
    };
  }
};

One neat little refactoring trick is that we can create a shared helper somewhere that returns a function which can be used or aliased in this export, like this:

// helper.ts
export const getUserFromServerSession = ({
  redirectToLogin,
}: {
  redirectToLogin?: boolean;
}) =>
  withSession(
    async ({ req }: GetServerSidePropsContextWithSession<{}>) => {
      try {
        const user = req.session.get<User>('user');

        if (!user) throw new Error('unauthorized');

        return {
          props: {
            user,
          },
        };
      } catch (err) {
        if (redirectToLogin) {
          return {
            redirect: {
              permanent: false,
              destination: '/login',
            },
          };
        } else {
          return {
            props: {},
          };
        }
      }
    },
  );

Then you can use that helper function in all your pages that need server side auth:

// some-page.tsx
export const getServerSideProps = getUserFromServerSession({
  redirectToLogin: true,
});

This way we don't have to repeat the same code in all our pages.

I am using next-iron-session for the session handling in case you're wondering. You can find an example in the Next.js repo.

When to use getServerSideProps

The Next.js docs state:

You should use getServerSideProps only if you need to pre-render a page whose data must be fetched at request time. Time to first byte (TTFB) will be slower than getStaticProps because the server must compute the result on every request, and the result cannot be cached by a CDN without extra configuration. If you don’t need to pre-render the data, then you should consider fetching data on the client side.

So be careful to use use complex logic or requests to external APIs from there. In our case we just check the request to see if we have a session cookie which is pretty fast and that way we can avoid unnecessary re-renders and redirects on the client side.

Client-Side authentication

So you have an site where users can log in. In the header or navigation bar you want to show a Login button when the user is logged out, or show an avatar when the user is logged in.
You also want to update the state throughout your application when a user decides to login or logout.
Indepentant of what provider you choose for your authentication, you'll want a React hook that you can use in any page or component that needs to access the user.

In order to create this hook I highly recommend you use React's context api. What you want it a single user object that you can access from anywhere within your app, so context is perfect for that.

First, create a context:

// AuthContext.tsx
import React from 'react';
import { Session } from '~/types';

const AuthContext = React.createContext<{
  user: Session | undefined;
  mutateUser: () => Promise<any>;
  logout: () => void;
}>({
  user: undefined,
  mutateUser: async () => null,
  logout: async () => null,
});

export default AuthContext;

Here we tell our app that there is a context that has 3 properties: the user, and a mutateUser and logout function. We don't initialize them yet though but just return noop functions and undefined for the user.

The next step is to create a Provider. Every context needs a provider, because the provider defines the scope of that context.

The provider usually gets added to the _app in Next.js apps (Usually you end up with multiple providers in bigger apps). So every component that is nested inside a provider can access that provider's context.

// pages/_app.tsx
import { AppProps } from 'next/app';
import { ApolloProvider } from '@apollo/client';
import { CSSReset, ChakraProvider } from '@chakra-ui/core';
import { useApollo } from '~/lib/apolloClient';
import { AuthProvider } from '~/components/auth/AuthProvider';

// eslint-disable-next-line no-console
const onError = (err: Error) => console.log(err);

const App = ({ Component, pageProps }: AppProps) => {
  const apolloClient = useApollo(pageProps.initialApolloState);

  return (
    <ApolloProvider client={apolloClient}>
      <ChakraProvider theme={customTheme}>
        <CSSReset />
        <AuthProvider>
          {/* eslint-disable-next-line react/jsx-props-no-spreading */}
          <Component {...pageProps} />
        </AuthProvider>
      </ChakraProvider>
    </ApolloProvider>
  );
};

export default App;

As you can see, here I have multiple providers, and sure enough we also find our AuthProvider in there. Now we can access its context from anywhere in the app!

The actual Provider could be implemented like this:

// AuthProvider.tsx
import React, { useEffect } from 'react';
import { useRouter } from 'next/router';

import useSWR from 'swr';
import { auth } from '~/services/auth';
import { Session } from '~/types';

import { post } from '~/utils/http';
import { jwt } from '~/utils/jwt';
import AuthContext from './AuthContext';

export function AuthProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  const { data: user, mutate: mutateUser } = useSWR<Session>(
    '/api/user',
  );

  const { push, pathname, query } = useRouter();

  const logout = async () => {
    await auth.logout();
    push('/');
  };

  useEffect(() => {
    // eslint-disable-next-line consistent-return
    auth.onIdTokenChanged(async _user => {
      if (!_user) return mutateUser(post('/api/logout'));

      await mutateUser(
        post('/api/session', { accountId: _user.uid! }),
      );

      const token = await auth.getLatestToken(_user);

      await jwt.save({ token });
    });

    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [user, mutateUser]);

  return (
    <AuthContext.Provider value={{ user, mutateUser, logout }}>
      {children}
    </AuthContext.Provider>
  );
}

We are using SWR and Firebase auth in this example but the implementation details don't matter. The important thing is that we attach the things we care about (user, mutateUser and logout) to the value property of the AuthContext.Provider and by doing this making it available throughout the app.

The actual hook itself now is super simple - it just returns the value from the AuthContext:

// hooks/useAuth.ts
import { useContext } from 'react';
import AuthContext from '~/components/auth/AuthContext';

export const useAuth = () => useContext(AuthContext);

Now whereever we want to access the user, we can just do

import { useAuth } from '~/hook/useAuth';

const { user } = useAuth();

Here are some other blog posts that were helping me on the way:

https://leerob.io/blog/nextjs-authentication
https://colinhacks.com/essays/nextjs-firebase-authentication
https://github.com/tmaximini/next-10-auth (the code examples for this post are there)

I hope that was useful! Enjoy your Next.js project!

This post was originally written and published on my blog

Cover Photo by Jonathan Farber on Unsplash

JWT Authorization for serverless APIs on AWS Lambda

Thomas Maximini — Wed, 11 Mar 2020 08:42:18 +0000

Serverless functions allow us to write small contained API endpoints for our apps. In this post we are going to learn how to secure our serverless API endpoint with a json web token (JWT) based authorization.

TL;DR

If you want to jump straight to the final code, you can find the repo here: https://github.com/tmaximini/serverless-jwt-authorizer

Read on for a full explanation of what is going on here.

Steps for JWT authorization

These are roughly the steps that we have to go through in order to secure our API endpoint:

Register with username, password, password hash gets stored in DB
Login with Username / Password
If hash of password matches stored passwordHash for user, generate a JWT token from user's id and their auth scope
Save token in Cookie 🍪
Sign every request with this token in the HTTP Authorization header
Setup authorizer function that verifies this token (on requesting a secured api route). authorizer response can be cached for a certain amount to increase api throughput.
Authorizer generates a policyDocument that allows or denies access to the service

Plan our app

We are going to need a registerUser and a loginUser method. We will also have an protected /me endpoint, that returns the the current user object if the user is authenticated correctly.

The verifyToken is an additional lambda function, that is defined as an API gatewa authorizer and will get called in the background whenever we try to access the protected /me endpoint.

So we have a total of 4 lambda functions:

Setup our app with serverless framework

So let's initalize the app. You will find the final code of the example in github. We can run serverless init --template aws-nodejs to bootstrap a node.js based project. Make sure you've setup the AWS cli before or at least you have a ~/.aws/credentials folder set up because this is where serverless will pull your information from.

Now we go and update the generated serverless.yml file. We are going to add all our functions from step 1 (register, login, me, verifyToken to it). It should look similar to this one:



    org: your-org

    service: serverless-jwt-authorizer
    provider:
      name: aws
      runtime: nodejs12.x
      region: eu-central-1
    functions:
      verify-token:
        handler: functions/authorize.handler

      me:
        handler: functions/me.handler
        events:
          - http:
              path: me
              method: get
              cors: true
              authorizer:
                name: verify-token
                            # this tells the lambda where to take the information from, 
                            # in our case the HTTP Authorization header
                identitySource: method.request.header.Authorization 
                resultTtlInSeconds: 3600 # cache the result for 1 hour
      login:
        handler: functions/login.handler
        events:
          - http:
              path: login
              method: post
              cors: true
      register:
        handler: functions/register.handler
        events:
          - http:
              path: register
              method: post
              cors: true

Folder structure for serverless APIs

The way I do it is to have a single file in ./functions for each Lambda. Of course you can export multiple functions from the same file but like this I keep sanity and it makes naming easier (each file exports a handler function that I use as the handler in serverless.yml).

All the helpers and non-lambda functions go into the ./lib folder.



    .
    ├── Readme.md
    ├── functions
    │   ├── authorize.js
    │   ├── login.js
    │   ├── me.js
    │   └── register.js
    ├── handler.js
    ├── lib
    │   ├── db.js
    │   └── utils.js
    ├── package.json
    ├── secrets.json
    ├── serverless.yml
    └── yarn.lock

The database layer

Now, before we can authorize a user, we are going to need a way to create a user and save them in the DB. We are going to pick DynamoDB as a database here because being a serverless database itself it is an excellent choice for serverless. Of course you could use any other database as well.

DynamoDB

Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale

DynamoDB works with a single table design. In our case, we just need a users table. I picked DynamoDB here because it is a famous and reliable choice for serverless APIs, especially because of the "pay as you go, scale as you grow" idea behind it.

If you want to know the ins and outs of DynamoDB I recommend you head over to https://www.dynamodbguide.com/ by @alexbdebrie.

The DB Model

When designing a service or an api I like to start with the data model. This is especially important with DynamoDB where we are limited by the single table design. This is why DynamoDB experts tell you to first write down all the access patterns and ways how you plan to query your data. Based on that you are going to model your table.

In our case, the schema is fairly simple for now, but we keep it generic enough to be able to extend it later on. I am using the dynamodb-toolbox package here to define my data model and simplify writing queries.



    const { Model } = require("dynamodb-toolbox");
    const User = new Model("User", {
      // Specify table name
      table: "test-users-table",

      // Define partition and sort keys
      partitionKey: "pk",
      sortKey: "sk",

      // Define schema
      schema: {
        pk: { type: "string", alias: "email" },
        sk: { type: "string", hidden: true, alias: "type" },
        id: { type: "string" },
        passwordHash: { type: "string" },
        createdAt: { type: "string" }
      }
    });

We will obviously not store the password in clear text in our database, so we use bcrypt (footnote about bcryptjs is the better choice on lambda) to create a passwordHash and then delete the original plain text password from the props object before spreading it into our user.

I chose the email here as a primary key and not the id because this is what I am using to query single items. You yould also use the userId or any combination.

It's important to not that DynamoDB can not fetch single items by non key properties, e.g. in the example above I am not able to say getById(id). I would have to fetch them first and then filter by using a FilterExpression.

The advantage of a NoSQL database such as DynamoDB is that columns and fields are dynamic. So if we decide to send more data to the createDbUser method they'll all get added to the database (We have to adjust the DB Model from dynamodb-toolkit first though).

Defining resources in serverless.yml

When we decided on our data model and table name it makes sense to revisit our serverless.yml and prepare the DynamoDB resource there, so we won't have to do any manual work from the AWS console. The serverless framework allows us to define resources and permissions right from the serverless.yml file.

We will also need a few secret environment variables. A simple way to define them is just creating a secrets.json file in your project root (make sure to .gitignore it!) and define them in a json format.



    org: your-org

    custom:
      secrets: ${file(secrets.json)}
      tableName: "test-users-table"

    service: serverless-jwt-authorizer
    provider:
      name: aws
      runtime: nodejs12.x
      region: eu-central-1
      environment:
        JWT_SECRET: ${self:custom.secrets.JWT_SECRET}
        AWS_ID: ${self:custom.secrets.AWS_ID}
      iamRoleStatements:
        - Effect: "Allow"
          Action:
            - "dynamodb:GetItem"
            - "dynamodb:PutItem"
          Resource: "arn:aws:dynamodb:eu-central-1:${self:custom.secrets.AWS_ID}:table/${self:custom.tableName}"
    functions:
      verify-token:
        handler: functions/authorize.handler

      me:
        handler: functions/me.handler
        events:
          - http:
              path: me
              method: get
              cors: true
              authorizer:
                name: verify-token
                identitySource: method.request.header.Authorization
                resultTtlInSeconds: 3600
      login:
        handler: functions/login.handler
        events:
          - http:
              path: login
              method: post
              cors: true
      register:
        handler: functions/register.handler
        events:
          - http:
              path: register
              method: post
              cors: true
    resources:
      Resources:
        usersTable:
          Type: AWS::DynamoDB::Table
          Properties:
            TableName: ${self:custom.tableName}
            AttributeDefinitions:
              - AttributeName: pk
                AttributeType: S
              - AttributeName: sk
                AttributeType: S
            KeySchema:
              - AttributeName: pk
                KeyType: HASH
              - AttributeName: sk
                KeyType: RANGE
            ProvisionedThroughput:
              ReadCapacityUnits: 1
              WriteCapacityUnits: 1

User registration

In order to let a user register for our service, we need to store their data in our database. With our data model in place, we can now use AWS DynamoDB DocumentClient together with our dynamodb-toolkit to simplify this process. Take a look at the following code:



    // lib/db.js

    const AWS = require("aws-sdk");
    const bcrypt = require("bcryptjs");
    const { Model } = require("dynamodb-toolbox");
    const { v4: uuidv4 } = require("uuid");

    const User = new Model("User", {
      // Specify table name
      table: "test-users-table",

      // Define partition and sort keys
      partitionKey: "pk",
      sortKey: "sk",

      // Define schema
      schema: {
        pk: { type: "string", alias: "email" },
        sk: { type: "string", hidden: true, alias: "type" },
        id: { type: "string" },
        passwordHash: { type: "string" },
        createdAt: { type: "string" }
      }
    });

    // INIT AWS
    AWS.config.update({
      region: "eu-central-1"
    });
    // init DynamoDB document client
    const docClient = new AWS.DynamoDB.DocumentClient();

    const createDbUser = async props => {
      const passwordHash = await bcrypt.hash(props.password, 8); // hash the pass
      delete props.password; // don't save it in clear text

      const params = User.put({
        ...props,
        id: uuidv4(),
        type: "User",
        passwordHash,
        createdAt: new Date()
      });

      const response = await docClient.put(params).promise();

      return User.parse(response);
    };

    // export it so we can use it in our lambda
    module.exports = {
      createDbUser
    };

This is enough for creating our user registration on the database side.

Now let's add the implementation for the actual lambda endpoint.

When getting triggered by an HTTP post, we want to extract the user data from the request body and pass it to the createDbUser method from our lib/db.js.

Let's create a file called functions/register.js that looks like this:



    // functions/register.js

    const { createDbUser } = require("../lib/db");

    module.exports.handler = async function registerUser(event) {
      const body = JSON.parse(event.body);

      return createDbUser(body)
        .then(user => ({
          statusCode: 200,
          body: JSON.stringify(user)
        }))
        .catch(err => {
          console.log({ err });

          return {
            statusCode: err.statusCode || 500,
            headers: { "Content-Type": "text/plain" },
            body: { stack: err.stack, message: err.message }
          };
        });
    };

We are trying to create the user, and if everything goes well we send the user object back with a 200 success status code, otherwise we send an error response.

Next, we are looking to implement the login.

Logging in users

First, we need to extend our lib/db.js helpers file with a function that retrieves an user by email, so we can check if the user exists and if so compare the passwordHash to the hash of the password that was sent with the request.



    //...

    const getUserByEmail = async email => {
      const params = User.get({ email, sk: "User" });
      const response = await docClient.get(params).promise();

      return User.parse(response);
    };

    // don't forget to export it
    module.exports = {
      createDbUser,
      getUserByEmail
    };

Now we can import and use this function in our user lambda.

Let's break down the steps we need for logging in the user:

get email & password from request payload
try to get user record from database for email
if found, hash password and compare with passwordHash from user record
if password is correct, create a valid jwt session token and send it back to the client

Here is the implementation of the login handler:



    // ./functions/login.js
    const { login } = require("../lib/utils");

    module.exports.handler = async function signInUser(event) {
      const body = JSON.parse(event.body);

      return login(body)
        .then(session => ({
          statusCode: 200,
          body: JSON.stringify(session)
        }))
        .catch(err => {
          console.log({ err });

          return {
            statusCode: err.statusCode || 500,
            headers: { "Content-Type": "text/plain" },
            body: { stack: err.stack, message: err.message }
          };
        });
    };

    // ./lib/utils.js
    async function login(args) {
      try {
        const user = await getUserByEmail(args.email);

        const isValidPassword = await comparePassword(
          args.password,
          user.passwordHash
        );

        if (isValidPassword) {
          const token = await signToken(user);
          return Promise.resolve({ auth: true, token: token, status: "SUCCESS" });
        }
      } catch (err) {
        console.info("Error login", err);
        return Promise.reject(new Error(err));
      }
    }

    function comparePassword(eventPassword, userPassword) {
      return bcrypt.compare(eventPassword, userPassword);
    }

With registration and login in place, we can now proceed to implement a protected API endpoint.

Protected endpoints

So let's say we have a protected resource in our API. A user profile might be a good example. We only want logged in users to be able to see and update their profile information. Let's implement a /me endpoint that just returns the user record of the currently logged in user from the database.

Here are the steps we need to implement:

validate jwt token (done by our lamda authorizer function)
get related user from database
return user

Sounds simple right? Let's take a look:



    // ./functions/me.js
    const { getUserByEmail } = require("../lib/db");
    const { getUserFromToken } = require("../lib/utils");

    module.exports.handler = async function(event) {
      const userObj = await getUserFromToken(event.headers.Authorization);

      const dbUser = await getUserByEmail(userObj.email);

      return {
        statusCode: 200,
        headers: {},
        body: JSON.stringify(dbUser)
      };
    };


    // ./lib/utils.js
    async function getUserFromToken(token) {
      const secret = Buffer.from(process.env.JWT_SECRET, "base64");

      const decoded = jwt.verify(token.replace("Bearer ", ""), secret);

      return decoded;
    }

The implementation of /me is fairly short and straightforward. The way AWS authorizers work is by using policy documents.

The policyDocument has to contain the following information:

Resource (The ARN orAmazon resource name, a unique identifier of a AWS resource)
Effect (either "allow" or "deny")
Action (a keyword that describes the desired action, in our case "execute-api:Invoke"

The authorizer function



    const jwt = require("jsonwebtoken");

    function generateAuthResponse(principalId, effect, methodArn) {
      const policyDocument = generatePolicyDocument(effect, methodArn);

      return {
        principalId,
        policyDocument
      };
    }

    function generatePolicyDocument(effect, methodArn) {
      if (!effect || !methodArn) return null;

      const policyDocument = {
        Version: "2012-10-17",
        Statement: [
          {
            Action: "execute-api:Invoke",
            Effect: effect,
            Resource: methodArn
          }
        ]
      };

      return policyDocument;
    }

    module.exports.verifyToken = (event, context, callback) => {
      const token = event.authorizationToken.replace("Bearer ", "");
      const methodArn = event.methodArn;

      if (!token || !methodArn) return callback(null, "Unauthorized");

      const secret = Buffer.from(process.env.JWT_SECRET, "base64");

      // verifies token
      const decoded = jwt.verify(token, secret);

      if (decoded && decoded.id) {
        return callback(null, generateAuthResponse(decoded.id, "Allow", methodArn));
      } else {
        return callback(null, generateAuthResponse(decoded.id, "Deny", methodArn));
      }
    };

Deploy and test

Now, let's run sls deploy and deploy our final service to AWS. The output should look like the following:

You'll have 3 endpoints, just as we defined them, one for /register, one for /login and one for /me.

First, let's register a user using cURL:



    curl -H "Content-Type: application/json" -X POST -d "{\"email\": \"test@example.com\", \"password\": \"test123\"}" https://abc1234567.execute-api.eu-central-1.amazonaws.com/dev/register

We can use the the same cURL command for login, just change /register to /login at the end:



    curl -H "Content-Type: application/json" -X POST -d "{\"email\": \"test@example.com\", \"password\": \"test123\"}" https://abc1234567.execute-api.eu-central-1.amazonaws.com/dev/login

This should return a token:



{"auth":true,"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InRtYXhpbWluaUBnbWFpbC5jb20iLCJpZCI6ImI5Zjc2ZjUzLWVkNjUtNDk5Yi04ZTBmLTY0YWI5NzI4NTE0MCIsInJvbGVzIjpbIlVTRVIiXSwiaWF0IjoxNTgzMjE4OTk4LCJleHAiOjE1ODMzMDUzOTh9.noxR1hV4VIdnVKREkMUXvnUVUbDZzZH_-LYnjMGZcVY","status":"SUCCESS"}

This is the token we are going to use for requests to the protected API endpoints. Usually you would store this in a client side cookie and add it as an Authorization header to your future requests.

And finally, let's use the token to test our protected endpoint. We can pass in the custom header to curl by using the -H option:

 curl -H "Authorization: <your token>" https://myn3t4rsij.execute-api.eu-central-1.amazonaws.com/dev/me

When everything went well, it should return our user record:



{"passwordHash":"$2a$08$8bcT0Uvx.jMPBSc.n4qsD.6Ynb1s1qXu97iM9eGbDBxrcEze71rlK","createdAt":"Wed Mar 04 2020 12:25:52 GMT+0000 (Coordinated Universal Time)","email":"test@example.com","id":"2882851c-5f0a-479a-81a4-e709baf67383"}

Conclusion

Congratulations. You've learned how to design and deploy a microservice to AWS Lambda with JWT authorization. If you made it this far please consider following me on Twitter.

Building a serverless GraphQL api with Node.js, AWS Lambda and Apollo

Thomas Maximini — Wed, 12 Feb 2020 10:07:32 +0000

Why serverless

What are the advantages of a serverless api?

Pay as you go: We have zero initial costs and pay only for what we actually use. So while we develop our app, we have close to zero costs, and depending on how it develops it will scale automatically when traffic increases.
Infinite Scaling: We don't have to deal with infrastructure or servers, so when our requests suddenly goes from 0 to 1000s of requests per second, it won't be a problem because the serverless api will scale automatically for us. (AWS handles that in the background)
Faster development: We don't have to deal with managing , installing and configuring servers, or with deployment processes, so we can just focus on the business logic and building our app.

Serverless might not be the answer for all our problems but an GraphQL server seems like a great use case, so let's dive right in.

Architecture

There are multiple providers for serverless functions, but the biggest and most famous one is AWS Lambda. This is the one we will be using here.
Other famous examples providers are Azure Functions, Google Cloud Functions and Cloudflare Workers.

To make our lives easier we are going to leverage the serverless framework for automating our deploys, so we can just define our deployment configuration in a serverless.yml file and don't need to worry about manual deployment.
Therefore we should install the serverless cli globally using npm install -g serverless. This installs a global cli tool which can be invoked by serverless or sls.

As a GraphQL server we are using Apollo, which is also one of the most famous graqhql clients and servers. Apollo Client now fully supports React Hooks which is one of the reasons I love using it.
The server-side implementation with Apollo is also very straightforward and they offer an AWS Lambda compatible package, apollo-server-lambda, which we are going to use in this tutorial.

Pre-Requisites

You should have an AWS Account and the AWS cli installed.
You should have run aws configure and setup your local machine with the AWS Access Key ID and AWS Secret Access Key from an IAM user with privileges to access DynamoDB.

The Apollo Server

GraphQL comes with a default UI, the grahiQL client, which gives us the possibility to inspect a schema and to request data from an API. Apollo Server also mocks our schema by default, so the initial setup of our GraphQL server is very compact - there is not much code needed at all to get started.

Assuming we are in a fresh project folder.



mkdir graphql-serverless-example
cd graphql-serverless-example
npm init -y\

First, let's do an



npm install apollo-server apollo-server-lambda graphql

I install both apollo-server and apollo-server-lambda here, because I want to develop most of the time locally and deploy to lambda every once in a while. Both the local and the lambda versions are going to use the same schema, so let's create a file grapqhl/schema.js from which we can then export our schema.



// schema.js
const { gql } = require("apollo-server-lambda");

const typeDefs = gql`
  type Image {
    source: String # Url scalar
    description: String
    thumbnailSource(width: Int, height: Int): String # Url scalar
  }

  enum Currency {
    EUR
    CHF
    USD
  }

  type Price {
    amount: Int
    currency: Currency
  }

  type Product @cacheControl(maxAge: 300) {
    id: ID!
    name: String
    description: String
    image: Image
    brand: String
    price: Price
  }

  type Query {
    product(id: ID!): Product
  }
`;

const resolvers = {};

const mocks = {};

module.exports = {
  typeDefs,
  resolvers,
  mocks,
  mockEntireSchema: true
};

This defines a fairly simple schema for Product which might resemble some form of e-commerce article data.

For quicker local development, we create a file local.js, where we import ApolloServer and our schema and fire up a local instance.



// local.js
const { ApolloServer } = require("apollo-server");

const { typeDefs, resolvers, mocks } = require("./graphql/schema");

const server = new ApolloServer({
  typeDefs,
  resolvers,
  mocks,
  mockEntireSchema: false
});

server.listen().then(({ url }) => {
  console.log(`🚀 Server ready at ${url}`);
});

For local development we will npm install --save-dev nodemon and add a npm script to our package.json:



"scripts": {
    "dev": "nodemon local.js"
  }

This will automatically restart the apollo-server in local.js whenever we change any files.

Fot the serverless function we create a file lambda.js with the following content:



// lambda.js
const { ApolloServer } = require("apollo-server-lambda");

const { typeDefs, resolvers, mocks } = require("./graphql/schema");

const server = new ApolloServer({
  typeDefs,
  resolvers,
  mocks,
  mockEntireSchema: false,
  context: ({ event, context }) => ({
    headers: event.headers,
    functionName: context.functionName,
    event,
    context
  })
});

module.exports = {
  server
};

This one is very similar to the local.js development server, except that we import ApolloServer from the apollo-server-lambda package now and we add some extra context object to the constructor (more on that later). We just export the the ApolloServer instance here again.

Now create another file, index.js, where we import said server.



// index.js
const { ApolloServer } = require("apollo-server-lambda");

const schema = require("./graphql/schema");

const server = new ApolloServer(schema);

exports.graphqlHandler = server.createHandler({
  cors: {
    origin: "*",
    credentials: false
  },
  endpointURL: "/graphql"
});

Now create the serverless.yml file.



org: tmaximini
app: apollo-lambda-app
service: apollo-lambda
provider:
  name: aws
  runtime: nodejs10.x
  region: eu-central-1
iamRoleStatements:
  Effect: "Allow"
  Action:
    - "dynamodb:GetItem"
    - "dynamodb:PutItem"
    - "dynamodb:Scan"
  Resource: "*"
functions:
  graphql:
    # this is formatted as <FILENAME>.<HANDLER>
    handler: index.graphqlHandler
    events:
      - http:
          path: graphql
          method: get
          cors: true
          integration: lambda-proxy

What is going on here? Serverless framework is configured using a yaml file - the most important point here are:

we want to use AWS as a provider (Lambda) with a nodejs runtime of version 10.x
we want to run it in eu-central-01 region (You might want to change that depending on your location)
we need some IAM policies
most importantly, we we tell serverless which functions should correspond to which endpoints: Here we have a function (we call it graphql) that uses the handler index.graphqlHandler, this means go check index.js for a function called graphqlHandler and then use this for the following event definitions, in our case a simple http get with a path of /graphql.

The first test

Let's run npm run dev and the local development server should start up:



🚀 Server ready at http://localhost:4000/

Now visit http://localhost:4000 and confirm everything works, you should see a GraphQL Playground.

Our GraphQL Playground at localhost:4000

As ApolloServer mocks everything by default, you can now run your first test query against the server:



{
  product(id: "123") {
    name
    brand
    price {
      amount
      currency
    }
  }
}

Fetching real data

Now if we want to display actual data, not just mock data, we have to write some resolvers.

As we want to stay serverless, we use AWS DynamoDB as a data layer in this example. DynamoDB is a "serverless" NoSQL Database service from AWS, that can handle large amounts of data easily and where we only pay for what we use.

To communicate with the DynamoDB locally, we need a .env file where we add the following information:



AWS_ACCCES_ID=<your access id>
AWS_SECRET_KEY=<your secret key>
AWS_REGION=<your region>

Make sure the .env file is git ignored and never gets checked into version control, as it contains sensitive information.

Now let's write our first resolver in resolvers/article.js.



const AWS = require("aws-sdk");

// this flag is set when the process runs on AWS lambda
// so we can use it to determine if we run on AWS or not
const isLambda = !!(process.env.LAMBDA_TASK_ROOT || false);

// if we are local, add env vars to communicate with DynamoDB
if (!isLambda) {
  require("dotenv").config();
  AWS.config.update({
    accessKeyId: process.env.AWS_ACCESS_ID,
    secretAccessKey: process.env.AWS_SECRET_KEY,
    region: process.env.AWS_REGION
  });
}

// we might need to transform the data from the DB format to
// whatever format works best for our client apps
const { transformArticle } = require("../transformers/article");

// INIT AWS
const docClient = new AWS.DynamoDB.DocumentClient();

// default DynamoDB params to be extended
const defaultParams = {
  // our DynamoDB table name
  TableName: "Articles",
  // the attributes that we want to get from that table
  AttributesToGet: ["ID", "Name", "Producer", "Description", "Price", "Images"]
};

// promisified generic getter
const getByParams = params =>
  new Promise((resolve, reject) => {
    docClient.get(params, (err, data) => {
      if (err) {
        console.log("error getting from dynamodb", err);
        reject(err);
      } else {
        // transform the DB result to desired format before returning
        const result = transformArticle(data.Item);
        console.log("yay got data from dynamodb", result);
        resolve(result);
      }
    });
  });

// our resolver function
const getArticleById = async id => {
  const params = {
    ...defaultParams,
    Key: {
      ID: id
    }
  };

  return getByParams(params);
};

module.exports = {
  getArticleById
};

The transformer function might look something like this - this really depends on your use case! You might not even need one depending on your data model.



const transformArticle = item => {
  return {
    id: item.ID,
    name: item.Name,
    image: item.Images.Image.Link,
    brand: item.Producer,
    slug: item.Slug,
    price: item.Price,
    description: Array.isArray(item.Translations)
      ? item.Translations[0].DescriptionLong
      : item.Translations.DescriptionLong || "no description yet"
  };
};

module.exports = {
  transformArticle
};

Now with our resolver in place, we can jump back into schema.js and actually use it:



// ...
const { getArticleById } = require("../resolvers/article");
// ...
const resolvers = {
  Query: {
    product(obj, args, context, info) {
      return getArticleById(args.id);
    }
  },
  Product: {
    price: obj => ({
      amount: obj.price,
      currency: "EUR"
    })
  }
};
// ...

We imported our resolver function and used it in the Query object of the resolvers object. the second argument, args, contains the request argumens, in this case id.

Nested resolvers, such as Product.price, get the parent object passed in as a first argument. This is pretty neat as it let's us abstract oder schema further into re-usable sub types, such as Price.

Deployment to serverless

Now you can run sls deploy and the project gets packaged and deployed to AWS Lambda. Your output should look something like this:

Our serverless deployment

Conclusion

Serverless technologies are changing the way we develop our applications. The fact that we don't need to think about infrastructure or optimise for later scaling gives us the possibility to laser focus on our apps. Another big plus is the low entry costs and not paying for any idle servers, we only pay for what is being executed. The downsides might be vendor lock-in into AWS, Google etc, because smaller businesses can just not compete with the services offered by large data centers of these providers.

You can find the code of this example on my Github.

Accessing Authorization headers in Apollo graphql client

Thomas Maximini — Fri, 24 Jan 2020 00:00:00 +0000

Use case

Let's say we have a graphql server that is setup using apollo-server.

In our app, the user arrives at the page and the page will do a request for a cart (e-commerce site). The cart is personalized that means it depends on a user. The user can be identified by a unique sessionId, which we store in a cookie. Therefore, we would have to access the response headers that are returned from a graphql call.

All our requests from the client are made via graphql using apollo-client. In case there is no sessionId, the graphql-server will issue a new sessionId and send it back in the "Authorization" header. We need to parse this header on the client, see if the Authorization header is set and if yes, store the sessionId in our cookie.

Problem

The Apollo client does not expose the response headers to client. We can use HttpLink to send custom headers to in our requests (which we will do to authorize via 'Authorization' header), but there is no direct way to handle the response headers.

Solution

First, we need to setup our apollo-link with a combination of HttpLink and a so-called afterware link. Afterware is a fancy term that I personally don't like very much, but basically it runs after the request is finished (as oposed to middleware which intercepts each request).

'Afterware' is very similar to a middleware, except that an afterware runs after a request has been made, that is when a response is going to get processed.

https://www.apollographql.com/docs/react/networking/network-layer/#afterware

This is how we instantiate the ApolloClient using our custom afterware to access the response headers:


import { InMemoryCache } from "apollo-cache-inmemory";
import { HttpLink } from "apollo-link-http";
import { ApolloClient } from "apollo-client";
import { ApolloLink } from "apollo-link";

const ENDPOINT = "https://your-gql-server.com";

function createApolloClient(initialState = {}) {
  const sessionID = getSessionID(); // get sessionID, e.g. from a cookie

  // create HttpLink with custom headers if we have sessionID
  const httpLink = new HttpLink({
    uri: "http://localhost:4000/graphql",
    headers: sessionID
      ? {
          Authorization: `Bearer ${sessionID}`
        }
      : {}
  });

  // our custom "afterware" that checks each response and saves the sessionID
  // if it contains an 'Authorization' header
  const afterwareLink = new ApolloLink((operation, forward) => {
    forward(operation).map(response => {
      const context = operation.getContext();
      const authHeader = context.response.headers.get("Authorization");

      // We would see this log in the SSR logs in the terminal
      // but in the browser console it would always be null!
      console.log(authHeader);

      if (authHeader) {
        // cut off the 'Bearer ' part from the header
        SESSION_ID = authHeader.replace("Bearer ", "");

        setSessionID(SESSION_ID); // save sessionID, e.g. in a cookie
      }

      return response;
    });
  });

  // this is how we combine middlewares in Apollo client
  const link = afterwareLink.concat(httpLink);

  return new ApolloClient({
    link, // use combined version for our final client
    cache: new InMemoryCache().restore(initialState)
  });
}

This looks pretty good so far. The problem that we faced now was that we would see the authHeader on the SSR logs but not in the browser console. Yikes!

'Access-Control-Expose-Headers' to the rescue

After an hour or so of tearing our hairs out we finally found the solution. As these graphql requests are CORS requests, we had to set the 'Access-Control-Expose-Headers' headers.

By default, only the 6 CORS-safelisted response headers are exposed (source):

The default ApolloServer from apollo-server can only take a boolean attribute cors. If set to true, apollo-server will add the cors middleware but with default values.

This is not enough in our case! As we learned this means it would just expose the 6 headers above.

In order to expose the header correctly we had to use the apollo-server-express package and set our custom corsOptions to the cors middleware (code below).


  import { ApolloServer } from 'apollo-server-express'

  import express from 'express'
  import { resolvers, typeDefs } from './schema'

  // we need custom cors options in order to pass through our Auth header to the client
  // this works only using apollo-server-express
  const app = express()
  const corsOptions = {
    origin: '*',
    credentials: true,
    exposedHeaders: ['Authorization'],
  }


  const server = new ApolloServer({
    typeDefs,
    resolvers,,
    context: (ctx) => {
      // get session, implementation omitted for clarity
      const session = getOrCreateSession()

      ctx.res.setHeader('Authorization', `Bearer ${session.id}`)

      return {
        session,
      }
    },
  })

  // apply cors middleware with our custom corsOptions
  server.applyMiddleware({ app, cors: corsOptions, path: '/' })

  app.listen({ port: 4000 }, () => {
    console.log("🚀 Server ready on port 4000")
  })

Conclusion

The key takeaway here is that apollo-server comes with a default options for cors, which works for most standard cases. If you want to have a custom cors configuration, you need to use apollo-server-express. And we learned that the CORS specification allows only the 6 CORS-safelisted response headers by default.