DEV Community: Samuel Danquah

Firebase and Fauna B2C Auth App in AWS Land

Samuel Danquah — Tue, 14 Dec 2021 05:34:11 +0000

Introduction

In the previous article, we explored the authentication offerings of Firebase to turbocharge your next Fauna-powered application and introduce the building blocks to architect applications for the client-serverless paradigm. Now we will build a serverless authentication business-to-consumer (B2C) backend with services from the AWS ecosystem. But first, let's look at a few prerequisites needed to begin our journey:

Requirements

Register for a Firebase account if you don't have one and enjoy the free tier. Payment information is not required to begin until you upgrade your plan.
Create a Fauna account and benefit from the free plan offerings. Payment information is not needed to get started.
Sign up for an AWS account if you don't already have an account with these instructions. A payment method is required to create an account and access the AWS free tier.

Authentication Requirements and Strategy

The client (frontend) application will communicate with our backend through an API. AWS provides API Gateway, which enables us to create, maintain, and secure our authentication API at any scale. API Gateway offers two RESTful API options for our B2C authentication application - HTTP and REST. Which option do we utilize for our business-to-consumer backend application? These two preliminary questions hold the clue to this puzzle:

Where are the target users located?
How do users access the authentication API?

This comprehensive guide helps you decide between the two for your application needs. For this sample application, we are working with the following assumptions:

Our users reside in a single continent.
Our users will access the authentication API from our client application.

Hence, we utilize the HTTP API option, which provides low latency and cheap regional API to proxy our business logic for authentication. AWS Lambda will encapsulate this business logic. To make working with the various AWS services a breeze, we will use the serverless framework. Let's build this faunabase authentication application.

Serverless Authentication App in AWS ecosystem

Faunabase Authentication App

We install the serverless framework and get a free dashboard account from this guide. If you don't have Node installed, be sure to do that first. The recommended NodeJS version for installation is the long-term support (LTS) version. Next, we create our faunabase-auth application using the AWS NodeJS template with the following command:

serverless create --template aws-nodejs --path faunabase-auth

or the shorthand version:

sls create -t aws-nodejs -p faunabase-auth

Open the faunabase-auth folder with your text editor and you should see the results below:

The command we run created two files: serverless.yml and handler.js. The serverless.yml file serves as the control panel to manage all our AWS infrastructure resources. Let's go through the default configuration and make a few customizations.

We will change the provider runtime from nodejs12.x to the current LTS version, which is nodejs14.x. We add a region and stage to the provider and set the default stage to dev and the default region to us-east-1 for this demo. Set this region to the location of your end-users. You should get the following results:

Let's clear all the comments to tidy up the serverless.yml file. Next, we set up our authentication API and integrate it with the business logic encapsulated in Lambda functions.

Setting up Firebase project

Before we proceed to create our API, let's create a Firebase project and Fauna database. Open the Firebase console and click the Create a project button.

Enter faunabase for the project name and click continue.

Click Continue and disable Google Analytics for this project. Finally, click on the Create project button to complete the process.

Click Continue to proceed to the project dashboard.

Click on the Settings gear icon button in the sidebar menu and select Project settings.

Copy the Project ID for the project and save it. We need it later for the authentication API.

Creating a Database in Fauna

Type faunabase-b2c as the database name, and select the United States option for the region group. Click on the Create button to complete the process.

We chose the United States region for data locality and better latency since our authentication API (AWS) is in the United States. Once the database is available, select the Security tab and choose New Key to create your first key. Accept the defaults of the current database and Server for the role. Enter AWS Serverless Framework as the Key Name, and choose Save to create a new key.

Copy the generated secret. We are going to store it in the next step.

Securing Secret with AWS Parameter Store

The secret we generated in the previous step provides unlimited access to the newly created database. We have to store it safely and provide access to our authentication API logic. Hence, we use Parameter Store to safeguard the secret using SecureString value, which encrypts the key accessed from the authentication API. Click on the Create parameter button.

Parameter Store creates the fauna-secret parameter and displays it on the My parameters tab. We will access this secret from our authentication logic encapsulated in our lambda functions.

Configure AWS Credentials for Serverless Framework

The Serverless Framework needs access to our AWS cloud account to create and manage resources on our behalf. Since we are using the serverless command-line interface (CLI) to set up our AWS credentials, we use an AWS profile and create an IAM user for the serverless framework. Ensure that you are logged in to your AWS account to proceed. Click on Users and then Add users. Type faunabase-serverless for the User name and tick the Access key checkbox to enable programmatic access. Click Next: Permissions to go to the permissions page.

Click on Attach existing policies directly. Select the AdministratorAccess option in the list, then click Next: Tags.

Add optional tags in the next step and select Review to complete the process. Check to make sure everything looks good and click Create user. View and copy the Access Key ID & Secret Access Key as we will use them in the next step to configure our serverless CLI.

It is important to note that the above step grants unrestricted access to resources in the AWS account and makes starting our application easy. The recommended security practice is to provide fine-grained permissions through IAM policies to match the scope of the application. Configure the serverless CLI with the following command using the copied values from the previous step:

serverless config credentials --provider aws --key copied-access-key-id --secret copied-secret-access-key

Next, we proceed to set up API Gateway and integrate it with Lambda functions.

Configuring API Gateway

Our authentication API has two endpoints: signup and login. The client applications will use the Firebase client SDK to request an ID token - a JSON Web Token (JWT). It will send this token to our authentication API, which will verify the integrity of the JWT before calling the business logic at the API endpoint. But first, let us do a little housekeeping in our faunabase-auth folder. Create a folder at the root location and name it src. Inside the src folder, we will create the following folders - functions, libs.

Delete the handler.js file. Next, let us set up our API in the serverless.yml file and connect it with the functions. In the YAML file under provider, add the apiName property and give it a value of auth-b2c-api. This value is our API Gateway name.

Delete the hello function with its handler property and add the httpApi property under provider. Next, set the cors and metrics properties to true under httpApi. We enabled Cross-Origin Resource Sharing (CORS) and Cloudwatch metrics by setting cors and metrics to true. With CORS, we can specify which clients can access our API and what actions they can take. We also set up monitoring and alerts for our API with Cloudwatch. We enable logging for API Gateway - type logs under provider. Next, set httpApi under logs to true. Let's set up authorization logic in the authentication API. Firebase has an OIDC discovery document that will help us verify users from our firebase project in our authentication API. First, we will need the firebase project ID from earlier when setting up our firebase account. Go to the URL below and replace project-id with your firebase project ID.

https://securetoken.google.com/project-id/.well-known/openid-configuration

In this demo, the project ID from the earlier is faunabase-687bd, so we visit the link below.

Our firebase project can accept and verify ID tokens from the discovery document. In serverless.yml, create authorizers property under httpApi. Under authorizers, we name our authorizer as firebaseB2CAuthorizer. We have to set an identity source, issuer URL, and audience. Under firebaseB2CAuthorizer, set identitySource to $request.header.Authorization, issuerUrl to https://securetoken.google.com/project-id, and audience to project-id. Remember to replace project-id with your Firebase project ID. Change the frameworkVersion value from '2' to '>=2.66.1 <4.0.0' - serverless framework at the time of this writing is transitioning from version 2 to version 3 which is currently in beta. Version 3 comes with breaking changes to the serverless.yml configuration. The current version of the stable serverless node library is 2.66.1. The current code can upgrade to the version 3 package when it becomes stable.

The frontend client must pass a valid Firebase ID token in the authorization header of the request. The identity source tells our authentication API where to find the ID token, a JWT to perform validation checks before providing access to the business logic encapsulated in a function. We have configured our authentication API. Now let's connect it to our two authentication endpoints - signup and login. We create the first endpoint for signing up. Navigate to the src folder --> then the functions folder. Create a signup.js and login.js file inside the functions folder.

Enter the code below in both the signup.js and login.js.

 module.exports.handler = async (event, context) => {


 }

We have set up the boilerplate code for our two endpoints - signup and login. Let's link the business logic to the endpoints in serverless.yml, beginning with the signup endpoint. Enter signup under functions. Next, we write the following code under signup:

functions:
  signup:
    handler: src/functions/signup.handler
    description: create user in fauna
    memorySize: 1048
    timeout: 15
    events:
      - httpApi:
          method: POST
          path: /signup          
          authorizer:
            name: firebaseB2CAuthorizer

the handler property sets the source file location for the business logic
the description property provides information about the business logic
the memorySize property sets the memory size for this business logic in MB
the timeout property determines how long the business logic is allowed to run before termination in seconds
the events property shows which AWS events can trigger the business logic to execute
the httpApi property under events tells us that the API Gateway HTTP API event can run this business logic
the method property under httpApi sets which HTTP method can access the API endpoint
the path property under httpApi sets the pathname for the API endpoint
Under httpApi, the authorizer property with name, its child property allows us to use the firebaseB2CAuthorizer we configured earlier to provide a security layer for the endpoint. Requests without a valid ID token from our Firebase project cannot execute the underlying business logic.

We have set up our signup endpoint for authentication API. Let's repeat the same process for our login endpoint. The final code configuration should look like this:

functions:
  signup:
    handler: src/functions/signup.handler
    description: create user in fauna
    memorySize: 1048
    timeout: 15
    events:
      - httpApi:
          method: POST
          path: /signup          
          authorizer:
            name: firebaseB2CAuthorizer
  login:
    handler: src/functions/login.handler
    description: login user in fauna
    memorySize: 512
    timeout: 10
    events:
      - httpApi:
          method: POST
          path: /login          
          authorizer:
            name: firebaseB2CAuthorizer

We have to make the database secret in Fauna available to the signup and login functions from the AWS Parameter Store. The serverless framework provides access to plugins. We will install the Serverless SSM Fetch plugin to help us retrieve the stored fauna secret in AWS. Run the command below to install the plugin as an npm package:

  serverless plugin install --name serverless-ssm-fetch

Add the installed plugin to the serverless.yml file with the following code at the root:

plugins:
  - serverless-ssm-fetch

Next, add a custom variable called FAUNA_SECRET as a property of custom.serverlessSsmFetch with this code:

custom:
  serverlessSsmFetch:
    FAUNA_SECRET: fauna-secret~true

The serverlessSsmFetch is an accessor provided by the plugin we installed, which decrypts the encrypted fauna-secret parameter with the ~true flag and automatically injects the AWS Parameter Store Fauna server key as an environment variable, accessible in all our functions. Add the logRetentionInDays property under provider and set the number of days to retain the Cloudwatch logs we set up for the authentication API. We proceed to code the business logic for signup and login. The current serverless.yml file should have the following results:

service: faunabase-auth
frameworkVersion: '>=2.66.1 <4.0.0'

provider:
  name: aws
  runtime: nodejs14.x
  apiName: auth-b2c-api
  httpApi:
    cors: true
    metrics: true
    authorizers:
      firebaseB2CAuthorizer:
        identitySource: $request.header.Authorization
        issueUrl: https://securetoken.google.com/faunabase-687bd
        audience: faunabase-687bd
  logs:
    httpApi: true
  logRetentionDays: 14
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-1'}
  lambdaHashingVersion: 20201221

plugins:
  - serverless-ssm-fetch

custom:
  serverlessSsmFetch:
    FAUNA_SECRET: fauna-secret~true

functions:
  signup:
    handler: src/functions/signup.handler
    description: create user in fauna
    memorySize: 1048
    timeout: 15
    events:
      - httpApi:
          method: POST
          path: /signup          
          authorizer:
            name: firebaseB2CAuthorizer
  login:
    handler: src/functions/login.handler
    description: login user in fauna
    memorySize: 512
    timeout: 10
    events:
      - httpApi:
          method: POST
          path: /login          
          authorizer:
            name: firebaseB2CAuthorizer

Business Logic in Lambda Functions

We need to create a collection in our database called User to house each user’s document. We access the database from our client application through FQL or GraphQL in Fauna. FQL can access resources created with the GraphQL API but not the converse. We create a main.gql file which we will upload to bootstrap resources for our database in this demo. Inside the src folder, navigate to the libs folder and create a new folder with fauna. Create a folder named schema within the fauna folder. Create the main.gql file inside the schema folder and type the following code in the schema:

type User {
  role: Role!
  email: String! @unique  
}

enum Role {
  ADMIN
  MEMBER
}

type Mutation {
  logoutUser: Boolean! @resolver(name: "logout_user")
}

In the code above, we started with creating a collection in our database using type User with the role and email attributes. We also set a uniqueness constraint on the email field to validate against duplicates using the @uinque directive. The role attribute will allow us to implement fine-grained access control for the database using User Defined Roles. The logoutUser mutation allows our client application to revoke the access token from the frontend. We will implement the logout logic in the logout_user User Defined Function (UDF).

On the Fauna dashboard, Select the faunabase-b2c database and click the GraphQL tab. Click on the IMPORT SCHEMA button to upload the schema we created.

If successful, you should obtain the following results:

Click on Functions located to the left of your Fauna dashboard. We will update the logic for the logout_user which was created when we uploaded our graphql schema.

Clear the contents of Function Body and replace it with the following code:

Query(
  Lambda(
    [],
    Logout(true)
  )
)

This logout logic revokes all authenticated token access for the current user. The client application can access this functionality from the GraphQL API. Click on the SAVE button to update the logout logic.

Setting up Libraries

Next, let’s install the fauna driver with this command inside our codebase:

  npm install --save faunadb

Create the firebase folder inside the libs folder in addition to the fauna folder. Also, create a util.js file inside the libs folder. The fauna folder will house all code about our Fauna database. The firebase folder will house functionality on Firebase authentication. The util.js file will contain all reusable utility functions which we will use in the login and signup endpoints. Paste the following code inside util.js:

const response = (code, message) => {
  return JSON.stringify({
    statusCode: code,
    body: message
  })
}

module.exports = { response }

The response function accepts an HTTP code and message and returns the response to the client application requesting the authentication API endpoint. The client application will send a request to API Gateway which will validate the JWT in the authorization header and call the AWS Lambda function. Inside the firebase folder, create an index.js which will contain logic to decode the JWT. Run the following code to install the jwt-decode node library:

 npm install jwt-decode

Enter the following code in the index.js:

const decode = require('jwt-decode')

const decodeJWT = (jwt) => {
  return decode(jwt)
}

module.exports = { decodeJWT }

The decodeJWT function accepts a JWT as input and decodes the payload. Inside the fauna folder, create a function.js file and paste the following code:

const {
  Create, Tokens, Ref, Match, Now,
  Collection, Select, Get, Index, TimeAdd
} = require('faunadb').query

const loginUDF = (email) => {
  return Create(
    Tokens(), {
      instance: Ref(
        Collection('User'),
        Select(
          ["ref", "id"],
          Get(
            Match(
              Index('unique_User_email'),
              email
            )
          )
        )
      ),
      ttl: TimeAdd(Now(), 1, 'hour')
    }
  )
}

const registerUDF = (email) => {
  return Create(
    Collection("User"),
    {
      data: {
        email,
        role: "MEMBER"
      }
    }
  )
}

module.exports = { loginUDF, registerUDF }

This file contains the signup and login business logic. The loginUDF exchanges the decoded Firebase JWT token for an access token to the Fauna database which is valid for one hour. The registerUDF creates a new user in the Fauna database with the decoded email input from the Firebase JWT and assigns a basic role of MEMBER. Finally, we export the loginUDF and registerUDF with module.exports. Next, we set up our Fauna client to query the database - create an index.js file and input the following code:

const faunadb = require('faunadb') // import faunadb driver
const { loginUDF, registerUDF } = require('./function') // import UDFs
// create new fauna client
const client = new faunadb.Client({
  secret: process.env.FAUNA_SECRET
})
// get Fauna access token from verified and decoded JWT
const login = (email) => {
  return client.query(loginUDF(email))
}
// create new Fauna user from verified and decoded JWT
const register = (email) => {
  return client.query(registerUDF(email))
}

module.exports = { login, register }

The code above imports the Fauna driver as well as the user-defined functions (UDFs) we created in function.js. A new Fauna client is instantiated to perform the login and register operations in our database. Finally, we export the login and register functions for use in our API endpoints. Next, we finalize the signup and login lambdas in the functions folder.

Open the signup.js file inside the functions folder. We import the register function, we just created from the index.js file with the following code:

const { register } = require('../libs/fauna')

We also import Firebase JWT decode function with this code:

const { decodeJWT } = require('../libs/firebase')

Next, we import the response function from the util.js file:

const { response } = require('../libs/util')

The handler function accepts event and context as inputs. The event input contains information such as the JWT token in the authorization header from the API invoker. The context input provides information on the invocation, function, and execution environment. Since AWS Lambda utilizes a pay-as-you-go model, we want to timeout our function immediately after receiving a response from our promise instead of waiting for the event loop to complete. We configure the runtime to send the response immediately with context.callbackWaitsForEmptyEventLoop to false inside the handler function to obtain the following code:

const { register } = require('../libs/fauna')
const { decodeJWT } = require('../libs/firebase')
const { response } = require('../libs/util')

module.exports.handler = async (event, context) => {
  context.callbackWaitsForEmptyEventLoop = false
}

Add the following code after context.callbackWaitsForEmptyEventLoop inside the handler function:

 try {
    const user = event.headers && event.headers.authorization
    ? decodeJWT(event.headers.authorization)
    : { email: null }


    if(!user.email) return response(401, "authorization header not found")
  } catch (error) {
     console.log("signup error", error.message)
  }

In the above code, we decode the JWT located in event.headers.authorization and store it in user if the authorization header exists, else we exit the function with a 401 HTTP response. Next, we implement the logic to create a new user in our Fauna database with the following code:

 const dbResponse = await register(user.email).catch(
  error => {
   console.log("create fauna user error", error.message || error.description)
    return response(500, "Oops! Something went wrong from our end.")
  }
 )
 if (
   dbResponse && dbResponse.data
   && dbResponse.data.email === user.email
 ){
   return response(200, dbResponse.data)
 }

If the register function executes successfully, dbResponse data is sent to the invoker and the function exited immediately. However, if an error occurs during this process, the invoker is notified and the error logged to AWS Cloudwatch Logs. The complete code for signup is shown below:

const { register } = require('../libs/fauna')
const { decodeJWT } = require('../libs/firebase')
const { response } = require('../libs/util')
module.exports.handler = async (event, context) => {
  context.callbackWaitsForEmptyEventLoop = false
  try {
    const user = event.headers && event.headers.authorization
      ? decodeJWT(event.headers.authorization)
      : { email: null }
    if(!user.email) return response(401, "authorization header not found")

    const dbResponse = await register(user.email).catch(
     error => {
      console.log("create fauna user error", error.message || error.description)
      return response(500, "Oops! Something went wrong from our end.")
     }
    )
    if (
      dbResponse && dbResponse.data
      && dbResponse.data.email === user.email
    ) {
      return response(200, dbResponse.data)
    }
  } catch (error) {
    console.log("signup trycatch error", error.message)
  }
}

Now, we implement the login lambda function.

Open the login.js file inside the functions folder. Next, we import the login function from the fauna folder, decodeJWT from the firebase folder, and response function from utils.js all located in the libs folder. Set the context.callbackWaitsForEmptyEventLoop to false inside handler like we did earlier in signup.js.The code should look like this:

const { login } = require('../libs/fauna')
const { decodeJWT } = require('../libs/firebase')
const { response } = require('../libs/util')

module.exports.handler = async (event, context) => {
  context.callbackWaitsForEmptyEventLoop =  false
}

Enter the following code after context.callbackWaitsForEmptyEventLoop inside the handler function:

try {
 const user = event.headers && event.headers.authorization
  ? decodeJWT(event.headers.authorization)
  : { email: null }
 if(!user.email) return response(401, "authorization header not found")
} catch (error) {
 console.log("login trycatch error", error.message)
}

Likewise in the signup lambda, we decode the JWT located in the event.headers.authorization and store it in user if the authorization header exists, else we exit the function with a 401 HTTP response. Next, we implement the login logic to create a user access token from the verified and decoded email with the code below inside the trycatch block:

 const dbResponse = await login(user.email).catch(
  error => {
   console.log("create fauna token error", error.message || error.description)
   return response(500, "Oops! Something went wrong from our end.")
  }
 )
 if (
   dbResponse && dbResponse.data
   && dbResponse.data.email === user.email
 ) {
      return response(200, dbResponse.data)
 }

On successful execution of the login function, dbResponse data is sent to the invoker and the function exited immediately. However, if an error occurs during this process, the invoker is notified and the error logged to AWS Cloudwatch Logs. The complete code for login is shown below:

 const { login } = require('../libs/fauna')
 const { decodeJWT } = require('../libs/firebase')
 const { response } = require('../libs/util')

 module.exports.handler = async (event, context) => {
  context.callbackWaitsForEmptyEventLoop =  false
  try {
   const user = event.headers && event.headers.authorization
    ? decodeJWT(event.headers.authorization)
    : { email: null }
   if(!user.email) return response(401, "authorization header not found")
   const dbResponse = await login(user.email).catch(
    error => {
     console.log("create fauna token error", error.message || error.description)
     return response(500, "Oops! Something went wrong from our end.")
    }
   )

   if (
      dbResponse && dbResponse.data
      && dbResponse.data.email === user.email
    ) {
      return response(200, dbResponse.data)
    }

  } catch (error) {
    console.log("login trycatch error", error.message)
  }
}

We have completed the signup and login lambda functions. Next, we look at the process to deploy the code to the AWS Cloud Service.

Deploy API to AWS

We are in the last mile of building our application and deploying it to the AWS cloud. Serverless Framework packages all node libraries and their dependencies which can result in very bloated lambda functions. Lambda functions in general are plagued by cold-starts which is the time taken to prepare the execution environment. This time scales with the code size. Therefore, we can reduce the cold-start time with webpack bundling, importing only the code needed for each function. The overarching benefit is that end-users get a better user experience with reduced latencies. The serverless-webpack plugin provides an option to achieve this optimization.

Webpack Bundle Setup

Install the serverless-webpack plugin, and webpack, as [devDependencies](https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file) with this code:

 npm install --save-dev serverless-webpack webpack

Go to the serverless.yml file at the root of the faunabase-auth folder and add the serverless-webpack plugin under plugins after serverless-ssm-fetch.
Next, we add the webpack configuration file to serverless.yml. Under the custom: property add the code below:

webpack:
    webpackConfig: 'webpack.config.js'

The serverless.yml file should be similar to the code below:

We exclude any GraphQL files (.gql) from the bundle with the excludeFiles property under webpack: in our src folder.

webpack:
    webpackConfig: 'webpack.config.js'
    excludeFiles: src/**/*.gql

After the plugins property at the root of the serverless.yml file add the code below to tell webpack to package our functions individually:

package:
  individually: true

The final serverless.yml file should have the following code:

service: faunabase-auth
frameworkVersion: '>=2.66.1 <4.0.0'

provider:
  name: aws
  runtime: nodejs14.x
  apiName: auth-b2c-api
  httpApi:
    cors: true
    metrics: true
    authorizers:
      firebaseB2CAuthorizer:
        identitySource: $request.header.Authorization
        issueUrl: https://securetoken.google.com/faunabase-687bd
        audience: faunabase-687bd
  logs:
    httpApi: true
  logRetentionDays: 14
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-1'}
  lambdaHashingVersion: 20201221

plugins:
  - serverless-ssm-fetch
  - serverless-webpack

package:
  individually: true

custom:
  serverlessSsmFetch:
    FAUNA_SECRET: fauna-secret~true
  webpack:
    webpackConfig: 'webpack.config.js'
    excludeFiles: src/**/*.gql

functions:
  signup:
    handler: src/functions/signup.handler
    description: create user in fauna
    memorySize: 1048
    timeout: 15
    events:
      - httpApi:
          method: POST
          path: /signup          
          authorizer:
            name: firebaseB2CAuthorizer
  login:
    handler: src/functions/login.handler
    description: login user in fauna
    memorySize: 512
    timeout: 10
    events:
      - httpApi:
          method: POST
          path: /login          
          authorizer:
            name: firebaseB2CAuthorizer

Create a webpack.config.js file in the root directory and import the serverless-webpack library:

const slsw = require('serverless-webpack')

The file we created will house all our code bundling configurations for deployment. Export an empty object with module.exports:

const slsw = require('serverless-webpack')

module.exports = {


}

Inside the empty object, we set the target property to node. At build time, the plugin can automatically determine the correct entry point for each lambda function. We set the entry to use slsw.lib.entries inside the exported object. Finally, we set mode to run in development mode if we are running locally else production mode with:

 slsw.lib.webpack.isLocal ? 'development' : 'production'

The final webpack configuration file should be similar to this result:

const slsw = require('serverless-webpack')
const nodeExternals = require('webpack-node-externals')

module.exports = {
  target: 'node',
  entry: slsw.lib.entries,
  mode: slsw.lib.webpack.isLocal ? 'development' : 'production'
}

Serverless Deploy to AWS Cloud

We run the serverless deploy command to deploy all artifacts to the AWS cloud with the default stage and region:

 serverless deploy

Summary

We have been able to build a serverless authentication API for a business-to-consumer application. The frontend or client application can access the signup endpoint to create a new user and the login endpoint to exchange a Firebase JWT for an access token to the Fauna database to facilitate direct communication. It is important to secure the access token with a user-defined role (UDR). We will do that in a future article in this series. In the next article, we explore building a serverless authentication API for a multi-tenant business-to-business application.

Authentication with Firebase and Fauna: Introduction

Samuel Danquah — Fri, 03 Sep 2021 20:36:43 +0000

Background

Getting authentication (authN) and authorization (authZ) right is vital to modern applications identifying legitimate users while controlling access to system resources. This process can be daunting for the novice as one wrong turn breaks the mantra - "a chain is only as strong as its weakest link." To the uninitiated, authN answers the question: is the user who they claim to be? Authentication precedes authorization but not the converse. AuthZ is primarily concerned with the inquest - are you permitted to access this resource? The journey from authN to authZ starts with the identity of the end-user.

An end-user of any application represents the basic unit or entity. However, it is not practical to fully describe the entity with regards to its attributes and actions. Therefore, an identity depicts a snapshot of properties that characterize an entity in the application's context. Furthermore, an entity can have multiple identities. Consider this instance - a citizen belongs to a country. A citizen can have multiple identification cards (contexts) such as a passport and driver's license. The internet has made it possible to have numerous identities scattered across social media and other online platforms. The average user today has one hundred online accounts, according to research from NordPass. This number could increase under the current global pandemic conditions as people subscribe to more online services. A close inspection of these scattered identities shows a duplication of similar attributes. What attribute is common to all identification cards for any citizen of a country? At least the full name is the common denominator. Asking new users for common attributes such as names creates fatigue on sign-up over time. The user experience is analogous to this scenario: someone walks up to you and asks, "have you eaten?" to which you reply, "Yes." A few minutes later, another person comes to ask the same question and you politely answer. If more people keep asking the same question, the situation escalates from politeness to "I dare you to ask that question again." This common situation can benefit from a federated identity. After a successful identity proof and verification, end users get an access token which they can use to access permitted resources. Next, we look at the authentication and authorization components of the software application. We begin with Firebase for authentication with its perks and benefits.

Authentication

Firebase authentication provides an identity management solution as a service offered by Google. It is not a silver bullet to authentication and leverages industry standards such as OAuth 2.0 and OpenID Connect. Hence, we investigate its benefits and offerings to meet the authentication requirements for your next software application.

Compliance, Privacy, and Security

Firebase authentication enables modern applications to surf the waves of privacy regulations. It meets the standards of the EU General Data Protection Regulation (GDPR). This regulation still applies to software applications having users located in the European Union (EU) despite operating primarily from a non-EU territory. Firebase acts as the data processor in GDPR land, with the business entity behind the software application starring as the data controller. Depending on the end-user roadmap and acquisition plan, the business entity will require a Data Protection Officer (DPO) stipulated in Article 37 of the GDPR. If a DPO is required, Firebase gives you an option to list the DPO on its cloud console. In addition, the California Consumer Privacy Act (CCPA) provides privacy regulations to protect only California residents. Firebase meets the requirements of the CCPA in the capacity of the service provider. Furthermore, Firebase authentication is certified under major privacy and security standards such as ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, and SOC 3.

Authentication Options

Firebase authentication provides several alternatives to authenticate end-users: email, password, phone number, federated identity, anonymous, and custom authentication systems.

Password authentication is the most common authentication method seen in software applications. The Open Web Application Security Project (OWASP) recommends that modern software applications transition to a post-password future, given the public release of over 5 billion password breaches down the years in the current version of the Application Security and Verification Standard (ASVS). The fundamental issue does not stem from the security robustness of password authentication systems but rather a behavioral defect from end-users often overlooked: the average user has numerous online accounts and is likely to reuse passwords across different accounts.; users generally are susceptible to generate weak passwords as it has to be memorable and easily remembered.

Email or passwordless authentication provides a much secure alternative to password authentication. It achieves this through the elimination of user behavior that can compromise the safety of authentication systems. One famous implementation is Slack's magic link login. However, critical observation on authenticating through email links raises concern as email channels also have vulnerabilities, such as phishing attacks and business email compromise (BEC) scams. It is important to note that compromised email accounts can also reset passwords in password authentication. There are no additional risks when comparing passwordless to password authentication. Having a second authentication factor, such as authenticator apps on the email channel, mitigates this risk directly.

Phone number or Short Message Service(SMS) authentication is considered a weak authenticator in the OWASP Application Security Verification Standard. SMS messages can be intercepted and compromised. The current version of the ASVS echoes this woe and recommends that modern applications begin a migration journey devoid of SMS as a future version of the current standard will phase it out. Hence, SMS is a weak link in the security chain whether used as the first or second authentication factor.

Firebase provides several federated identity providers out of the box, creating a frictionless authentication option. These include Facebook, Google, Twitter, Github, Apple, Twitter, and Microsoft. Do software applications using Firebase federated identity authentication have to write code for multi-factor authentication? Examining the problem closely with a focus on user experience brings to light the following observations: federated identity providers have native multi-factor authentication. Rolling out multi-factor authentication code in your software application becomes redundant when already enabled on the federated identity provider. Hence, end-users should be encouraged to use multi-factor authentication ingrained in the federated identity provider. However, end-users must be encouraged to avoid SMS as a second authentication factor to keep the security integrity of the authentication system.

Branding, and UI Customization

Firebase authentication allows for the complete customization of the entire authentication experience for beginners with speed and ease. Nobody sets out to build a bespoke authentication solution unless your business is identity like Auth0. Firebase authentication provides an open-source user interface (UI) library which streamlines building diverse authentication flows for a great user experience. These flows come with the wisdom of years of UX research optimizing the authentication on Google, Youtube, and Android to get you started.

Availability and Scalability

Firebase authentication does not offer service level agreements (SLA). It comes at no cost and does not limit the number of monthly active users (MAU). It charges using SMS verifications which impacts authentication security negatively. If SLA guarantees are a requirement for your business, consider using the Google Cloud Identity Platform or any other identity provider (IDP) that meets your SLA needs. Firebase authentication shines for new ventures and small and medium enterprises who need to cut costs at the onset in uncertain business climates. Despite not having an SLA, you can investigate the availability guarantees from the Firebase authentication status history. For instance, the downtime in 2019 was 1 hour, 48 minutes which is about 3 minutes shy of a 99.98% uptime SLA. The previous year's SLA was much worse, with an approximate 99.4% SLA. As a free service, Firebase operates within certain tenable limits. The authentication API can handle a maximum of 10 million request operations per day.

SDK Integrations

Firebase authentication has support for web, ios, android, c++, and unity platforms on clients. Software development kit (SDK) libraries are available for the supported platforms providing coverage for use cases across mobile, web, internet of things (IOT), and games coupled with documentation. The beta release of the client SDKs provides up to an 80% reduction in file size for the web platform. However, the beta release library will not work with the Google Cloud Identity Platform and the open-source Firebase UI library.

It also offers admin libraries for secure server environments with Node, Python, Java, and Go making it a breeze to work with for serverless architectures.

Additional Considerations

Firebase provides other additional services such as Google Analytics, Cloud Storage, and Cloud Messaging that pair well with Firebase authentication. Analytics helps you target a segment of end-users who can receive messages inside the software application at no cost.

Cloud storage provides a scalable file storage option that uses security rules to provide authorization logic for file access. It integrates seamlessly with Firebase authentication using identity attributes to give permissions to file resources.

For advanced authentication needs such as support for SAML and OIDC, Firebase authentication leverages identity-aware proxies (IAP) to external providers, not covered under the initial identity provider offerings. Furthermore, the native Microsoft federated identity can connect to Azure Active Directory (AD). This access provides support for Web Services (WS) Federation protocol giving access to the Microsoft ecosystem.

Authorization

The client-serverless model is enabling modern applications to encapsulate business and application logic close to the underlying resources. Fauna facilitates authorization logic encapsulated in User Defined Roles (UDR) and User Defined Functions (UDF) using Attribute-Based Access Control (ABAC) for authZ at the database layer. This approach means public clients can talk directly to the database in a secure fashion. Other critical non-database business services run in serverless functions behind a serverless API gateway with inherent authorization logic.

When public clients use bearer tokens, software applications must mitigate cross-site scripting (XSS) attacks. A compromised application can steal bearer tokens - whether in memory or service workers.

Next, we look at architectural components for our serverless identity solution.

Modern Application Architecture

Software application architecture has evolved through generations, giving birth to the modern client serverless architecture. Despite the leaps from generation to generation, the underlying component layers remain almost the same. These components are the presentation, application, business, and data layers.

The presentation layer, also referred to as the view or user interface layer is where users access software applications directly through public clients such as browsers and mobile applications. Public clients, by nature, are not capable of keeping passwords or secrets private.

The application layer does overlap with the business layer. The requirements for building software applications determine the extent of the overlap. The application layer is a gateway to the business layer when encapsulating an API interface to business functionality from the presentation layer. The business layer houses the business rules that govern the set of problems that the application should address. The data layer handles the persistence and storage of data in databases and file storage systems. One factor guiding communication between these layers concerning authorization is that logic for granting permissions should reside close to the resource it controls. The penalty for going contrary is two folds: it increases latency and can lead to a bad user experience; it creates a bottleneck when the server housing the authorization logic is offline while the resource server is online and creates an inconvenience. If the authorization logic and permitted resource reside on the same server, an outage reflects that both are unavailable and notify the end-user of the situation.

In the next installment of this series, we assemble the building blocks to implement a business-to-consumer (B2C) client-serverless architecture and build a serverless authentication solution with Amazon Web Services (AWS).

Collaborative Editing with Gridsome and FaunaDB: Introduction

Samuel Danquah — Fri, 26 Jun 2020 01:33:58 +0000

Document Conventions

The following conventions are employed throughout this article.

JAMstack	Javascript, Api’s, and Markup technology stack
CMS	Content Management System
OT	Operational Transformation
CRDT	Conflict-Free Replicated Data Types
CmRDT	Commutative Replicated Data Types
P2P	Peer-to-Peer
ABAC	Attribute-Based Access Control

Background

The dawn of Web 2.0 sparked an explosive interest in browser-based document editing tools. Today, creating contents necessitate collaboration to arrive at the final masterpiece - a gestalt in addition to the many revisions throughout a content’s life cycle. Google Docs, a free collaborative editing tool, gained a meteoric rise in the collaborative editing space on the bedrock of real-time collaboration. In this modern era of the JAMstack, headless content management systems provide a cheap, scalable, and developer-friendly approach to content creation and management in contrast to classical monoliths. However, the concept of collaborative editing is not native to the JAMstack ecosystem of headless CMS nor its monolithic predecessors. Therefore, we observe mundane use cases where content collaboration happens on Google Docs (and other alternatives) before content transfer to a CMS of choice. This approach throttles down on the overall productivity engine of the user experience. How can dynamic JAMstack applications trapped in this scenario surmount this bottleneck? To answer this question, we explore the real-time collaborative editing landscape available to the JAMstack ecosystem as a starting reference, the challenges, and finally build a collaborative text editor using WebRTC with data persistence to FaunaDB.

But first, we will dive under the hood of a real-time collaborative editor to comprehend the moving parts and their integration.

Mechanics of a real-time collaborative editor

Version control system like Git is the polar opposite of a real-time collaborative editor. A real-time collaborative editor has a singular goal of providing consensus across multiple users editing the same content in near real-time at its foundation. Furthermore, a practical distributed team of content editors may place additional constraints on the ability to collaborate on slow and flaky internet connections with seamless content resynchronization capabilities as a minimum requirement. Fundamentally, a real-time collaborative editor mandates a delicate balancing act across the trident of clients (content editors), concurrency (simultaneous editing), and communication (centralized or decentralized).

Clients

Clients represent end-users who need to collaborate on content with write permissions in real-time. The number may vary depending on the size of the collaboration team wanting to edit the content at any instant of time (Figure 1). Increasing clients spike the complexity of scalability for any given collaborative editing solution. For example, Google Docs allows a maximum of 100 users to both comment and edit a document at the same time.

Concurrency

Concurrency relates to conflicts that are bound to arise from clients simultaneously editing the same content and a primary challenge for real-time collaborative editing. Addressing this issue requires a blend of concurrency control and consistency maintenance across all simultaneous users accessing the content. Whether creating, updating, or deleting content from concurrent actions from users, collaborative editing operations can be classified as insert and delete actions at a basic level. A real-time collaborative editor then has to satisfy two challenging axioms: commutativity and idempotency.

Commutativity: Concurrent insert and delete operations converge to the same result despite the order of application.
Idempotency: Repeated delete operations must produce the same result.

Real-time collaborative editing solutions diverge into two broad strategies to tackle these challenges. The first and popular approach is Operational Transformation (OT). This strategy gave birth to the first generation of real-time collaborative editors - Etherpad, Firepad, Google Wave, among others. However, OT is more complicated to implement in a decentralized communication model than a centralized one. The plethora of OT algorithms with several trade-offs published in academic papers to address a fully distributed approach highlights the complexities involved. Current real-time collaborative editors still use OT and mostly adopt a centralized communication model. The alternative approach to OT is Conflict-Free Replicated Data Types (CRDT). Researchers discovered this alternate strategy in a quest to improve the robustness and simplicity of OT. CRDT has created a new generation of real-time collaborative editors.

Communication

Communication protocols provide an avenue to relay content changes from the content creator to other concurrent content editors. The major obstacle with real-time communication is the physical distance between users for which there are no plausible solutions. The two prevalent models are centralized and decentralized architectures.

Centralized Architecture

This architecture (Figure 2) relies on a client-server model. It requires a central server to mediate content changes between multiple concurrent clients and achieve convergence across users. The central server handles concurrency control and consistency maintenance.

Paradoxically, it serves as both a single source of truth for conflict resolutions as well as a single source of failure. If the server fails, content editors can no longer collaborate. Another limitation is the introduction of undesirable high latencies between nearby clients who are both far away from the central server (Figure 3). The central server has to receive content updates from one user(Anna) for conflict resolution before sending it to another user(Evan) even though they are near (10ms) to each other. Furthermore, a centralized server presents scaling challenges for increasing large distributed clients.

Decentralized Architecture

This architecture is a peer-to-peer system. Each end-user(peer) acts as both client and server with direct communication between users and no need for a central server. However, a signaling server is required to broker the initial peer-to-peer connections and serves no further purpose. After, clients exchange content updates directly. WebRTC is the protocol that enables real-time communication among concurrent users and is present in modern browsers. This decentralized approach is in stark contrast to the centralized architecture (Figure 4) and does not suffer from the issues of a centralized server. However, there is a limit on the maximum number of peer-to-peer connections possible, and the client browser decides this limit. For instance, the Chromium browser sets a limit of 500 peer-to-peer connections from its source code.

Comparison of real-time collaboration solutions

This is not an exhaustive list and is meant to be a referencing guide.

	Yjs	CKEditor	Collab	ShareDB
Communication	P2P	Centralized	Centralized	Centralized
License	MIT	Proprietary	MIT	MIT
Network-agnostic	Yes	No	No	No
Offline editing	Yes	No	`No	Yes
Algorithm	CRDT	OT	Reconciliation	OT
Supported Editors	ProseMirror	CKEditor	ProseMirror	CodeMirror
	Quill			Quill
	Monaco			Ace
	Ace
	CodeMirror
Support Content Types other than Text	Yes	No	No	Yes
Scalable	Yes	Yes	No	Yes
Server Data Loss Sync	Yes	No	No	No

Real-time collaborative text editor: Case Study

Let us look at a hypothetical company X with a real-world collaboration problem while building a real-time collaborative text editor solution in the process:

Background

Company X has a small distributed team of content editors, spread across the US and Europe who have to collaborate on contents simultaneously. For every published content, 30 content editors (maximum) have to work simultaneously. Company X seeks a seamless solution to the problem, and like most companies is on a tight budget. How can company X address this issue? We are going to explore an example application to cover this use case.

The maximum number of clients working at any instant on a single content is 30. Next, we have to look at concurrency control and what communication protocols present a united front on efficiency and cost. Do we employ an OT or CRDT approach for concurrency and conflict resolution? An OT strategy simplifies concurrency to one conflict at a time, which a centralized server can resolve before propagating content changes to all clients. However, this solution is also a single point of failure and has little fault tolerance. If the central server goes offline at any point, the team cannot collaborate, which is undesirable. OT also creates inefficiencies as content editors living in nearby neighborhoods always have to send content updates first to a distant central server for conflict resolution before neighboring content editors can receive the content changes. Lastly, running on a central server for conflict resolution implies OT brings extra costs for a tight budget. We already have non-negotiable bills for persisting content updates to a database. It is important to note that in other scenarios where a large distributed team needs to collaborate simultaneously, server costs for communication is inevitable. Can a CRDT alternative solve these challenges for company X with a tight budget? Contrary to OT, CRDT provides a decentralized autonomous conflict resolution strategy without a central server for concurrency control irrespective of the number of connected clients (content editors). This approach eliminates a single point of failure observed in the OT strategy and is more fault-tolerant.

Furthermore, CRDT guarantees automatic content synchronization across all connected clients. For clients with flaky internet connections, content updates are seamless upon reconnection and resolve to a unified state for the team of content editors. In the earlier situation of nearby content editors with the distant central server, CRDT has an option for direct peer-to-peer communication through protocols such as WebRTC present in modern browsers. This option for P2P can save costs for running active communication servers. However, CRDT needs a signaling server to establish the initial direct connection among peers or clients. This signaling server is analogous to a matchmaker for clients and takes no further part in the actual communication of content updates among connected clients. There are free to use public signaling servers as well as self-hosted private options. In summary, our solution will employ a CRDT strategy, and hence we use Yjs, a network agnostic shared editing framework.

Lastly, we need to persist the content to a database. Since we are working with a distributed team of content editors, FaunaDB presents a viable solution (Figure 5) for data persistence with its global serverless database, which provides low latency data access and distributed ACID transactions without sacrificing data consistency.

Yjs has integrations for several text editors, as seen in the comparison chart for real-time collaborative editing solutions. For our scenario, we use ProseMirror, an open-source toolkit for building renderless and extensible rich text editors. Yjs also provides a communication connector for webRTC, among others. We will use this connector (y-webrtc) in our application, which satisfies our current threshold of 30 maximum collaborators per document or content for company X. Now, we have the ingredients to make a real-time collaborative text editor with data persistence. But, how secure is this system end to end?

Security

Figure 6 shows the communication model for our decentralized real-time collaborative editing solution. Communication channels exist across client to client (P2P), client to FaunaDB, and the client to signaling server bridges. From figure 6, Evan creates the document for collaboration with a unique room attribute as well as a shared secret attribute and persists to FaunaDB (GraphQL or FQL).

Through FaunaDB’s attribute-based security model (ABAC), we can implement fine-grained access control for collaborators (content editors). Hence, Evan grants Anna collaboration rights to his document. Evan retrieves the document from FaunaDB in our real-time collaborative text editor. This communication channel between Evan (client) and FaunaDB (database) is secure over HTTPS, among other security mechanisms. Communication between client and database is an already solved problem, especially for JAMstack apps.

Therefore, we focus on the other two communication channels, according to Figure 6. Next, both Evan and Anna access our real-time collaborative editing (we-collab) app. They both communicate with the signaling server, which is responsible for handling unique and relevant signaling information such as the IP address and facilitates the necessary exchange of this information to connected clients. Signaling servers follow a publish-subscribe pattern. Yjs provides an option for a shared secret as well as a room for collaboration. FaunaDB secures this information with its strong ABAC model. Yjs uses the shared secret to encrypt the information exchange from the client to the signaling server.

Hence, Evan and Anna can exchange signaling information securely, even on a public signaling server without any trust. Yjs also provides an option to utilize multiple signaling servers in our we-collab app for scalability.

Finally, the last communication channel occurs between clients, in our case Evan and Anna (Figure 6). Clients receive content updates through webRTC, directly from one client browser to the other. How secure is webRTC? This a legitimate concern, and the answer is VERY SECURE. WebRTC employs biometric encryption protocols with content sharing across encrypted data channels from peer to peer. Therefore content updates exchanged among peers (clients) are secure by default. The tight coupling of Yjs, webRTC, and FaunaDB with its strong ABAC model provides an end to end security for this application.

We-Collab App

We will now proceed to build the we-collab app using Gridsome(Vue) for Markup, WebRTC for peer-to-peer communication, and FaunaDB for data persistence, through its GraphQL API. Let’s get started:

Backend

Login to your FaunaDB account and create a new database collab from the cloud console. Next, create a schema.gql with the following code and upload it to the cloud console.

type Page {
   name: String! @unique
   room: String! @unique
   secret: String
   type: PageType!
   content: String!
 }

 enum PageType {
   PUBLIC
   PRIVATE
 }

 type Query {
   allPages: [Page!]
   findPageByName(name: String!): Page
 }

Let’s create some data into the collab database. Go to the GraphQL Playground in the cloud console and run the following code:

mutation createPublicPage {
  createPage(
    data: {
      name: "Public Page"
      room: "live-wall"
      type: PUBLIC
      secret: "afreeworld"
      content: ""
    }
  ){
    _id
    name
    room
    type
    secret
    content
  }
}

If successful, your screen should look similar to the picture below (Figure 7):

Lastly, we create a Guest Role using ABAC from FaunaDB. Still logged in, click on the SECURITY tab to the left of your screen, highlighted below.

Next, click on MANAGE ROLES as shown below.

Select NEW ROLE to create our guest role.

On the new screen, change MyCustomRole text to Guest.

Add the Page collection with Read and Write privileges under Collections. Next, add the findPageByName index with Read permission under Indexes. Lastly, add collections with Read and Write privileges under Schemas. Your screen should be similar to image below and click Save.

We can now create a new key for the Guest Role by clicking on NEW KEY under the SECURITY tab as shown below:

Next, choose the collab (Current Database) under Database, and select Guest under Role. You can also provide an optional key name. Select Save when you are done.

You should see the screen below with the guest key to connect our frontend. Save this key as an environment variable. In our frontend, we use this key as the GRIDSOME_GUEST_KEY variable. Now we are going to connect our frontend to FaunaDB’s GraphQL API.

Frontend

Our frontend uses vuetify for UI. Vuetify is a Vue UI library that comes out of the box with ready-to-use handcrafted material design components. We set up our application to consume the FaunaDB GraphQL API. Since we are not utilizing GraphQL subscriptions, we use Axios, a lightweight HTTP client library. You can also use the native browser Fetch API or the graphql-request library, a minimal GraphQL client. We create a mutation with the following code, to update our database with the current document version in a mutation.js file.

export const updatePageMutation = (payload) => {
   return `
     mutation updatePublicPage{
       updatePage(
         id: "${payload._id}"
         data: {
           content:"${payload.content}"
           name: "${payload.name}"
           room: "${payload.room}"
           type: ${payload.type}
         }
       ) {
         _id
         name
         room
         secret
         type
         content
       }
     }
   `
}

Next, we create a query in a _query.js _file with the following code to fetch a document (content) from our database with the updated document version, whenever a new client (content editor) opens our app for the first time.

export const getPageQuery = (payload) => {
   return `
     query getPage {
       getPage: findPageByName(
         name: "${payload}"
       ) {
         _id
         name
         room
         secret
         type
         content
       }
     }
   `
}

This content has two vital attributes (room and shared secret) for integration with Yjs. Then we create an index.js that houses HTTP calls to our database for queries and mutations through the GraphQL API with the following code:

import { guest, page, url } from "./config"
import { updatePageMutation } from "./mutation"
import { getPageQuery } from './query'
import axios from 'axios'

export const updatePage = (dataPayload) => {
   return axios({
       method: 'post',
       url,
       headers: {
           "authorization": `Bearer ${guest}`
       },
       data: {
           query: updatePageMutation(dataPayload)
       }
   })
}

export const getPage = async () => {
   return await axios({
       method: 'post',
       url,
       headers: {
           "authorization": `Bearer ${guest}`
       },
       data: {
           query: getPageQuery(page)
       }
   })
}

We now look at integrating Yjs as a real-time extension to the ProseMirror text editor in our app. Since we are using Gridsome, we will use Tiptap, a Vue flavored ProseMirror text editor. We begin by adding Yjs and y-webrtc connector to the realtime.js file.

import * as Y from 'yjs'
import { WebrtcProvider } from 'y-webrtc'

Next, we create an extension for our real-time collaboration functionality with the code below:

import * as Y from 'yjs'
import { WebrtcProvider } from 'y-webrtc'
import { Extension } from 'tiptap'


export default class Realtime extends Extension {
  get name() {
    return 'realtime'
  }
}

Our real-time extension accepts a document from our getPage query. We create a new instance for both Yjs and the y-webrtc connector and pass the fetched document from the database in the init function. We are storing the content for collaboration as a string in FaunaDB whereas Yjs uses the content as a Uint8Array. Therefore, we use the fromBase64 and toBase64 to handle the conversion between Uint8Array and a Base64 String. Every time the document is updated with the update hook of Yjs, all connected clients receive just the update and not the whole state of the document. At the same time, we persist the entire state of the document to FaunaDB. Any new client who joins to collaborate will first fetch the current copy from the database and receive direct incremental updates from connected clients as real-time updates arise. Y-webrtc also provides an option to set the maximum number of allowed connections per client browser. We set the maximum number of connected clients per client browser with maxConns. It is important that we add an element of randomness to connected clients to prevent them from forming clusters as shown in the code below:

import * as Y from 'yjs'
import { WebrtcProvider } from 'y-webrtc'
import { Extension } from 'tiptap'
import { fromBase64, toBase64 } from '@aws-sdk/util-base64-browser'

export default class Realtime extends Extension {
  get name() {
    return 'realtime'
  }
  get defaultOptions() {
    return {
        pageDoc: {},
        type: null,
        provider: null
    }
  }
  init() {
      const ydoc = new Y.Doc()

      if (
          typeof this.options.pageDoc.content === 'string' &&
          this.options.pageDoc.content.length !== 0
      ) {
          this.options.pageDoc.content = fromBase64(this.options.pageDoc.content)
          Y.applyUpdate(ydoc, this.options.pageDoc.content)
      }

      ydoc.on('update', update => {
          this.options.pageDoc.content = toBase64(Y.encodeStateAsUpdate(ydoc))
          updatePage(this.options.pageDoc)
      })

      this.options.provider = new WebrtcProvider(
          this.options.pageDoc.room, ydoc, {
              password: this.options.pageDoc.secret,
              maxConns: 40 + Math.floor(Math.random() * 30),
          }
      )
      this.options.type = ydoc.getXmlFragment('prosemirror')
  }
}

Yjs also provides shared editing cursors for connected clients just like in Google Docs to create a better user experience for all connected clients with undo and redo capabilities. You can customize what happens for undo and redo in the shared editing space. Finally, we add the shared editing cursors to our app with the code below:

import { keymap } from 'prosemirror-keymap' 
import { Extension } from 'tiptap' 
import { redo, undo, yCursorPlugin, ySyncPlugin, yUndoPlugin } from 'y-prosemirror' 
import * as Y from 'yjs' 
import { WebrtcProvider } from 'y-webrtc' 
import { updatePage } from '@/services/fauna/index.js' 
import { fromBase64, toBase64 } from '@aws-sdk/util-base64-browser' 
 
export default class Realtime extends Extension { 
    get name() { 
        return 'realtime' 
    } 
 
    get defaultOptions() { 
        return { 
            pageDoc: {}, 
            type: null, 
            provider: null 
        } 
    } 
    init() { 
        const ydoc = new Y.Doc() 
 
        if ( 
            typeof this.options.pageDoc.content === 'string' && 
            this.options.pageDoc.content.length !== 0 
        ) { 
            this.options.pageDoc.content =     fromBase64(this.options.pageDoc.content) 
            Y.applyUpdate(ydoc, this.options.pageDoc.content) 
        } 
 
        ydoc.on('update', update => { 
            this.options.pageDoc.content = toBase64(Y.encodeStateAsUpdate(ydoc)) 
            updatePage(this.options.pageDoc) 
        }) 
 
        this.options.provider = new WebrtcProvider( 
            this.options.pageDoc.room, ydoc, { 
                password: this.options.pageDoc.secret, 
                maxConns: 40 + Math.floor(Math.random() * 30), 
            } 
        ) 
        this.options.type = ydoc.getXmlFragment('prosemirror') 
    } 
 
    get plugins() { 
        return [ 
            ySyncPlugin(this.options.type), 
            yCursorPlugin(this.options.provider.awareness), 
            yUndoPlugin(), 
            keymap({ 
                'Mod-z': undo, 
                'Mod-y': redo, 
                'Mod-Shift-z': redo 
            }) 
        ] 
    }

The final code is available at this repo. Finally, we have built a real-time collaborative text editor for company X. You can play around with the demo (Figure 8) at https://we-collab.netlify.app.

Conclusion

In this article, we took a deep dive under the hood of a real-time collaborative text editor to understand its internal mechanisms and moving parts. We explored the real-time collaborative editing solution landscape to provide viable options to build a real-time collaborative text editor for various use cases. We saw firsthand how webRTC can provide both a low-cost and secure option for real-time collaboration for small distributed teams.

Finally, the globally distributed architecture of FaunaDB with strong consistency and low latency provides a unique set of complements to any real-time collaborative editing solution. Let’s not forget FaunaDB’s powerful ABAC feature provided out of the box to implement robust security and expand the creative freedom to architect security solutions for various use cases without any external setup.

DEV Community: Samuel Danquah

Firebase and Fauna B2C Auth App in AWS Land

Introduction

Requirements

Authentication Requirements and Strategy

Faunabase Authentication App

Setting up Firebase project

Creating a Database in Fauna

Securing Secret with AWS Parameter Store

Configure AWS Credentials for Serverless Framework

Configuring API Gateway

Business Logic in Lambda Functions

Setting up Libraries

Signup Lambda

Login Lambda

Deploy API to AWS

Webpack Bundle Setup

Serverless Deploy to AWS Cloud

Summary

Authentication with Firebase and Fauna: Introduction

Background

Authentication

Compliance, Privacy, and Security

Authentication Options

Branding, and UI Customization

Availability and Scalability

SDK Integrations

Additional Considerations

Authorization

Modern Application Architecture

Collaborative Editing with Gridsome and FaunaDB: Introduction

Document Conventions

Background

Mechanics of a real-time collaborative editor

Clients

Concurrency

Communication

Centralized Architecture

Decentralized Architecture

Comparison of real-time collaboration solutions

Real-time collaborative text editor: Case Study

Background

Security

We-Collab App

Backend

Frontend

Conclusion