AWS isn't the cheapest Cloud anymore. Or is it?

Tired of users blowing up your emails, saying they can’t register?

In Cognito, you get to choose a custom self-registration solution.

Users can sign-up using an email, phone number, or username for your application. Leave handling the backend (user data validation) to AWS. I’m serious.

Yeah, fine. But can Amazon Cognito seriously dethrone Firebase?

Yes and yes.

Cognito is a strong alternative to Firebase, especially when combined with other AWS services.

Cognito is the industry choice — specially when it comes to user authentication and authorization.

And when coupled with its fellow AWS service brothers and sisters, it’s near to invincible.

Not to brag, but here are all the duties Amazon Cognito can do better than Google Firebase:

• User sign-up, sign-in, multi-factor authentication (MFA), and account recovery
• Social identity providers (Google, Facebook, etc.) and enterprise identity providers (SAML 2.0)
• Integrates well with other AWS services like API Gateway, Lambda, and DynamoDB
• High scalability and reliability for handling large volumes of users and requests
• Developers can create custom authentication flows using AWS Lambda triggers
• Compliance and Security (HIPAA + GDPR)

Are you an AWS developer who’s still using Firebase for things you didn’t know Cognito could do for you?
It’s time you make the jump switch.

AppSync GraphQL resolvers: Before JavaScript (VTL)

GraphQL mutation schema:

type Mutation {
  updatePost(
    id: ID!
    author: String!
    title: String!
    content: String!
    url: String!
  ): Post
  addPost(
    author: String!
    title: String!
    content: String!
    url: String!
  ): Post!
}

Request mapping template for updating an item in DynamoDB:

{
    "version" : "2017-02-28",
    "operation" : "UpdateItem",
    "key" : {
        "id" : $util.dynamodb.toDynamoDBJson($context.arguments.id)
    },
    "update" : {
        "expression" : "SET author = :author, title = :title, content = :content, #url = :url ADD version :one",
        "expressionNames": {
            "#url" : "url"
        },
        "expressionValues": {
            ":author" : $util.dynamodb.toDynamoDBJson($context.arguments.author),
            ":title" : $util.dynamodb.toDynamoDBJson($context.arguments.title),
            ":content" : $util.dynamodb.toDynamoDBJson($context.arguments.content),
            ":url" : $util.dynamodb.toDynamoDBJson($context.arguments.url),
            ":one" : { "N": 1 }
        }
    }
}

Response mapping template for updating an item in DynamoDB:

$utils.toJson($context.result);

AppSync GraphQL resolvers: After JavaScript

Request and response mapping template for updating an item in DynamoDB (combined in a JS file):

import { util } from "@aws-appsync/utils";
import * as ddb from "@aws-appsync/utils/dynamodb";

export function request(ctx) {
  const { id, expectedVersion, ...rest } = ctx.args;
  const values = Object.entries(rest).reduce((obj, [key, value]) => {
    obj[key] = value ?? ddb.operations.remove();
    return obj;
  }, {});

  return ddb.update({
    key: { id },
    condition: { version: { eq: expectedVersion } },
    update: { ...values, version: ddb.operations.increment(1) },
  });
}

export function response(ctx) {
  const { error, result } = ctx;
  if (error) {
    util.appendError(error.message, error.type);
  }
  return result;
}

Tell me the difference isn’t striking.

Let’s see AWS CDK for what it really is.

Your AWS infrastructure is just CDK. Your CDK code is just Cloudformation. Your Cloudformation is just YAML / JSON. And that YAML / JSON just calls AWS APIs.

Funny, ain’t it?

That’s it for this newsletter.
It took me 6 hours to write, and would take you just 5 seconds to reply.