DEV Community: Sandro Volpic

How to add custom resources to AWS Amplify. Add an SQS queue that triggers lambda.

Sandro Volpic — Thu, 04 Nov 2021 15:33:41 +0000

AWS Amplify is allowing you to build cloud-connected apps very easily. It has a broad range of categories it supports natively which you can use to build (see my post here). But there are still some major components missing, such as SQS and RDS. In this post, I want to show you how to add AWS services that are not currently supported in Amplify. We start with the general steps you need to take for adding these resources. In the second part, I show you how to add an SQS queue that triggers a lambda.

There are many ways of doing this but I think the easiest is to use CloudFormation. It is also possible to use frameworks like CDK or Terraform but CloudFormation is best integrated into Amplify. All deployments and updates will still happen from the Amplify CLI and no other tool is needed. All code is in this repo.

How to add custom resources in general

Amplify has a docs page here on how to add custom AWS resources. We need to do basically two steps.

Add custom resource in backend config

In the first step, you need to add a custom category name and custom resource name within your backend config amplify/backend/backend-config.json.

{
  "<custom-category-name>": {
    "<custom-resource-name>": {
      "service": <custom-aws-service-name>,
      "providerPlugin": "awscloudformation"
    }
  }
}

This could look like that. Remember that Amplify always uses the category name as a prefix. Think about that when using the names to not have the same category all over the resource names.

Add custom folders & CloudFormation

After that, you need to add the folders you referenced your category and resource names to.

amplify
  \backend
    \<custom-category-name>
      \<custom-resource-name>
        parameters_<custom-resource-name>.json
        template_<custom-resource-name>.json

template_<custom-resource-name>.json: CloudFormation Templat
parameters_<custom-resource-name>.json: Additional parameters for CloudFormation

You need both the parameters and the template files. Create them directly with the suffix custom-resource-name to avoid any name clashes in the future.
Now you would need to add your CloudFormation code in the template file. We'll see that in a second.

Reference existing parameters

The good thing here now is that you can reference output parameters of other CloudFormation categories. For example if you need the lambda ARN which was added by Amplify you can reference it in a dependsOn block in the backend-config.json.

{
  "<custom-category-name>": {
    "<custom-resource-name>": {
      "service": <custom-aws-service-name>,
      "providerPlugin": "awscloudformation",
      "dependsOn": [
        {
          "category": "function",
          "resourceName": "lambda", // check `amplify status` to find resource name
          "attributes": [
              "arn" // Check Output Value of the resource specific cloudformation file to find available attributes
            ]
        }
      ]
    }
  }
}

Input parameters need to be defined in the created template_<custom-resource-name>.json file. The format is <category><resource-name><attribute-name .

{
"Parameters": {
  "functionlambdaarn": { 
    "Type": "String"
  }
}
}

The last step for referencing is to get the value into CloudFormation as well. For that you need to add an Fn:GetAtt to your attribute name.

{
  "functionlambdaarn": {
    "Fn::GetAtt": [
      "functionlambda",  
      "Outputs.ARN"
    ]
  }
}

Finally, you need to check out your environment again and push it to the cloud with amplify env checkout <ENV> and amplify push.

So that is the theory and seems a lot first. Let's add an SQS queue and see how it works in reality.

Add a custom SQS queue

We want an SQS queue that has access to a lambda function. At this point we don't care about what triggers the queue and which messages it will send, we simply want to create it.

In this setup we have an active Amplify application and have created one lambda function named service.

Backend Config

First of all, we add a custom SQS resource. I am in root of my project and show you the following steps you need to do to create the queue. We start by editing the amplify/backend/backend-config.json

{
  "function": {
    "service": {
      "build": true,
      "providerPlugin": "awscloudformation",
      "service": "Lambda"
    }
  },
  "queue": {
    "users": {
      "service": "SQS",
      "providerPlugin": "awscloudformation"
    }
  }
}

We added the queue parameter. Several things are defined here:

queue: That is the new category name. In lambda, it is function.
standardQueue: That is the resource name. That is how you name your queue. In lambda, this is service.
service: This is the custom AWS service we want to use. In this case, it is SQS.
providerPlugin: That is the provider we use for provisioning the resources. In our case and mostly with Amplify this is CloudFormation.

CloudFormation

Now we need to add the folders we need:

mkdir -p amplify/backend/queue/users
touch amplify/backend/queue/users/parameters_users.json
touch amplify/backend/queue/users/template_users.json

Now let's first fill the template_users.json. We need to add the CloudFormation code here.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Queue resource stack creation using Amplify CLI",
    "Parameters": {
        "env": {
            "Type": "String"
        }
    },
    "Conditions": {
        "ShouldNotCreateEnvResources": {
            "Fn::Equals": [
                {
                    "Ref": "env"
                },
                "NONE"
            ]
        }
    },
    "Resources": {
        "SQS": {
            "Type": "AWS::SQS::Queue",
            "Properties": {
                "QueueName": {
                    "Fn::If": [
                        "ShouldNotCreateEnvResources",
                        "users",
                        {
                            "Fn::Join": [
                                "",
                                [
                                    "users",
                                    "-",
                                    {
                                        "Ref": "env"
                                    }
                                ]
                            ]
                        }
                    ]
                }
            }
        }
    },
    "Outputs": {
        "Name": {
            "Value": {
                "Ref": "SQS"
            }
        },
        "Arn": {
            "Value": {
                "Fn::GetAtt": [
                    "SQS",
                    "Arn"
                ]
            }
        },
        "Region": {
            "Value": {
                "Ref": "AWS::Region"
            }
        }
    }
}

At this point, we can push the SQS queue to the cloud and create it.

amplify env checkout <ENV> # e.g. dev
amplify push

The output of amplify push should now be:

❯ amplify push
✔ Successfully pulled backend environment dev from the cloud.

    Current Environment: dev

┌──────────┬───────────────┬───────────┬───────────────────┐
│ Category │ Resource name │ Operation │ Provider plugin   │
├──────────┼───────────────┼───────────┼───────────────────┤
│ Queue    │ users         │ Create    │ awscloudformation │
├──────────┼───────────────┼───────────┼───────────────────┤
│ Function │ service       │ No Change │ awscloudformation │
└──────────┴───────────────┴───────────┴───────────────────┘
? Are you sure you want to continue? (Y/n)

Let's hit Y and deploy our SQS queue.

Let's check the CloudFormation template. Go to your Amplify console → find your environment and click on View in CloudFormation.

If you look at one of the nested stacks you will see that your SQS queue was created:

Now open SQS and you see your queue being ready to process some messages.

Lambda Consumer

Now we want to connect our SQS queue with our lambda function. To accomplish that we need to connect the lambda with our SQS queue and then define that queue as the trigger for the lambda. We already added the URL and ARN of our SQS queue in the outputs section of the CloudFormation template. That means that the CloudFormation template will output these two parameters after it is finished and other resources have access to these parameters. Let's now use this as an input for lambda. For that, we need to edit the amplify/backend/backend-config.json file again.

"function": {
    "service": {
      "build": true,
      "providerPlugin": "awscloudformation",
      "service": "Lambda",
      "dependsOn": [
        {
          "category": "queue",
          "resourceName": "users",
          "attributes": ["Name", "Arn"]
        }
      ]
    }
  }

We change the function part of the file so, that we are depending on the category queue with our exact name users and the attributes we want to pass.

Now we just need to update the CloudFormation template of lambda to receive and handle these params.

Open amplify/backend/function/service/service-cloudformation-template.json and edit the following things:

You need to add your queue name and queue ARN as an input parameter in the section Parameters
You define the name of the SQS queue as an environment variable in the section Resources/LambdaFunction/Environment/Variables

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "Lambda Function resource stack creation using Amplify CLI",
  "Parameters": {
# THIS IS ADDED in the format <CATEGORY RESOURCE>Name (without space)
    "queueusersName": {
      "Type": "String",
      "Default": "queueusersName"
    },
# THIS IS ADDED in the format <CATEGORY RESOURCE>Arn (without space)
    "queueusersArn": {
      "Type": "String",
      "Default": "queueusersArn"
    }

  },
  ...
  "Resources": {
    "LambdaFunction": {
      "Type": "AWS::Lambda::Function",
      "Metadata": {
        "aws:asset:path": "./src",
        "aws:asset:property": "Code"
      },
        ...

        "Environment": {
          "Variables": {
# THIS IS ADDED: Same name as above
            "SQS_QUEUE": {
              "Ref": "queueusersName"
            },
            "ENV": {
              "Ref": "env"
            },
            "REGION": {
              "Ref": "AWS::Region"
            }
          }
        },
        "Role": {
          "Fn::GetAtt": [
            "LambdaExecutionRole",
            "Arn"
          ]
        },
        "Runtime": "nodejs14.x",
        "Layers": [],
        "Timeout": 25
      }
    },
   ...
  }
}

After checking out the environment and pushing again with amplify env checkout dev && amplify push -y you see that the URL was added as an environment variable in lambda.

SQS as input trigger

Finally, let's call the lambda from the SQS queue. The connection of the environment variable should show how to pass arguments. Don't send a message from the SQS queue and call the lambda from the SQS queue because this ends up in a loop.

To add the queue as an input trigger we need to edit the CloudFormation template again. We will add the following things:

Add LambdaFunctionEventSourceMapping and add the SQS URL here
Add an IAM policy statement to give it access to the resource

See the full file here

{...
  "Resources": {
    "LambdaFunctionEventSourceMapping": {
      "DependsOn": [
        "lambdaexecutionpolicy"
      ],
      "Type": "AWS::Lambda::EventSourceMapping",
      "Properties": {
        "EventSourceArn": {
          "Ref": "queueusersArn"
        },
        "FunctionName": {
          "Ref": "LambdaFunction"
        }
      }
    },
# ADD THIS
    "lambdaexecutionpolicy": {
      "DependsOn": [
        "LambdaExecutionRole"
      ],
      "Type": "AWS::IAM::Policy",
      "Properties": {
        "PolicyName": "lambda-execution-policy",
        "Roles": [
          {
            "Ref": "LambdaExecutionRole"
          }
        ],
        "PolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
# ADD THIS
            {
              "Effect": "Allow",
              "Action": [
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes"
              ],
              "Resource": {
                "Ref": "queueusersArn"
              }
            },
            ...
                ]
    }
...

Let's push again amplify env checkout dev && amplify push -y and see that our lambda function now has SQS as a trigger

Finally just change the resource in the IAM policy of the CloudFormation template to:

"Statement": [
            {
              "Effect": "Allow",
              "Action": [
                "sqs:ReceiveMessage"
                "sqs:DeleteMessage",
                "sqs:GetQueueAttributes"
              ],
              "Resource": {
                "Ref": "queueusersArn"
              }
            },

With that, we follow the least privileged principle and don't give lambda access to all resources. This wasn't possible before because Amplify wouldn't recognize it.

Now we see that the IAM policy is restricted on this one resource.

Now we can go to SQS, send a message and see that the lambda was executed successfully.

The video shows it as well but can't be embedded right now 🤷🏽‍♂️

Summary

That's it. It seems a bit much at the beginning but with CloudFormation and Amplify you are very flexible in how to add and connect different resources.

Here is a short summary of the steps needed to do:

Custom resource in backend config
Folders & CloudFormation for custom resource
Pass parameter from SQS to lambda from backend config
Adjust CloudFormation template in lambda to use the parameter

If you want to know more about serverless, AWS, and building SaaS products on the cloud follow my Twitter 🙂

References: https://medium.com/@navvabian/how-to-add-an-sqs-queue-to-your-amplify-cli-bootstrapped-project-cb7781c636ed

What can you build with AWS Amplify? Let's see all categories and services.

Sandro Volpic — Fri, 22 Oct 2021 05:44:00 +0000

What can you build with AWS Amplify? Let's see all categories and services.

Build serverless Apps with Amplify!

AWS Amplify is a lot. In my last post I already explained the different products Amplify refers to. In this blog post, I want to show which categories and services can be used by the Amplify CLI and Amplify Libraries.

As a short reminder, the CLI is here to bootstrap infrastructure based on a data schema and a CLI wizard. The libraries give us access to AWS components in different languages, mainly JavaScript.

I will go through all available categories, show a short example use-case and the involved AWS services.

You can see all available categories on the main page of the Amplify Docs.

Authentication

AWS Services: Cognito

Description: Authentication refers to all functionality regarding user registration, Sign-In, Social Sign-In, and restricting access to certain users or user groups. Example use cases here are all basic authentication procedures in your app. Social Sign-In via Facebook, Apple, Google, & Amazon is supported natively. All typical workflows like password forget, multi-factor authentication, and much more are supported.

Use-Case: User Sign-In, Sign-Up with social providers.

Functions

AWS-Services: Lambda

Description: The category function is missing in the overview but I think it is one of the most important ones. Function handles everything regarding creating lambda functions. Especially, the handling of requirements, providing access to other AWS resources, and using lambda layers are really great within Amplify. Runtimes available:

Python
NodeJS
.NET
Go
Java

One of the latest news is that you also can use environment variables and secret parameters within Amplify and everything will be provisioned automatically.

Use-Case: Periodically update your database with new data, for example run a lambda daily at 12pm.

Storage

AWS-Services: DynamoDB, S3

Description: Storage refers to all functions regarding persisting data. This could either be object storage such as S3 or a NoSQL database like DynamoDB. A relational database is not supported (yet) in Amplify. The storage component makes it really easy to persist and access your data. Especially, when using DynamoDB, Amplify CLI, and GraphQL it is fairly easy to connect several tables and build a complex and high-performing data model.

Use-Case: Uploading and downloading images from your app.

GraphQL API

AWS-Services: AppSync

Description: The category GraphQL API refers to the AWS service AppSync. AppSync is a fully-managed GraphQL API and it has some real benefits. First of all, it is fully managed. That means you don't have to handle any scalability or infrastructure issues. Secondly, you get a lot of things built in. For example, real-time subscriptions are automatically included in AppSync. You can build several authorization methods for your API like API keys, IAM users, or even a lambda authorizer. AppSync also allows an offline mode in combination with Amplify's DataStore to enable offline capabilities.

Use-Case:All API-related backends can be built with AppSync. Live updates on a news feed or stock price.

DataStore

AWS-Services: AppSync, DynamoDB

Description: The DataStore category gives you the ability to persist data online and offline on your device. Under the hood, the services AppSync and DynamoDB are used for synchronizing the content. It is also possible to use it completely offline without any AWS account. As a query language also GraphQL is used.

Use-Case: Mobile social media app.

Geo

AWS-Services: Amazon Location Service

Description: Geo is one of the newer services of AWS. It provides interfaces to the newly introduced Amazon Location Service. With this service, it is easily possible to build map and location web applications. UI components from maplibre can be used to combine AWS location service with the maplibre UI. You can do several things with the Geo service such as:

Displaying maps
Put markers on the map
Draw points on the map
Search for certain locations

Use-Case: Map enabled web applications.

REST API

AWS-Services: API Gateway

Description: In the same way you can use a managed GraphQL API (AppSync) you can also use a fully managed REST API → API Gateway. With API gateway you can create several endpoints with the same authorization methods and use input and output templates for your data flow. Often times you will use lambdas as a resolver for resolving the given endpoints.

Use-Case: Any application which needs an API 😉

Analytics

AWS-Services: PinPoint, Kinesis

Description: Analytics gives us the opportunity to get insights into our user behavior. AWS PinPoint and Kinesis are used for this purpose. With Analytics you can track sessions of your user and also create custom events that should be tracked. Analytics data can also be streamed directly to kinesis for further analysis. PinPoint in general even allows more functions, for example sending out newsletters and creating different campaigns is also possible. Within Amplify the main functionality is analyzing user behavior.

Use-Case: Analyse how users are using your app.

Push Notifications

AWS-Services: PinPoint

Description: Push notifications handles everything related to notifying your users. Some things have to be configured to get it running on iOS and Android. Push notifications are currently just supported for React-Native projects.

Use-Case: Notify your mobile users when receiving new messages on a social media app.

XR

AWS-Services: Amazon Sumerian

Description: XR allows you to build Augmented Reality and Virtual Reality applications. It supports one of the lesser-known AWS Services → Amazon Sumerian. With Sumerian, you are able to build 3D scenes and display them via your Amplify App.

Use-Case: AR application for supporting car mechanics

PubSub

AWS-Services: AWS IoT

Description: With the PubSub category you are able to build messaging-oriented applications which can publish and subscribe data for a certain middleware. AWS IoT is the preferred and supported middleware in this category. Other middlewares such as MQTT or WebSockets are also possible. Basically, you can subscribe and publish data to a message broker.

Use-Case: Weather station with many sensors.

Interactions

AWS-Services: Amazon Lex,

Description: Interactions gives you the possibility to build interactive chatbots with the Amazon Lex service. I already made a post about that. Lex is the service that is also used by Amazon Alexa, so it is battle-proven. The great thing is that Amplify is also offering a UI component for the Chatbot interface which makes it really easy to set up a complex chatbot within minutes for yourself.

Use-Case: Customer service chatbot.

AI / ML Predictions

AWS-Services: Polly, Translate, Transcribe, Rekognition, Comprehend

Description: The AI and ML Prediction category offers several things. These are:

Text to speech: Polly
Transcribe audio or text: Transcribe
Translate languages: Translate
Identify Text: Rekognition
Identify entities: Rekognition
Label objects: Rekognition
Interpret sentiment: Comprehend

The great thing about this category and the different services is that you do not need any data science knowledge for building applications that use a lot of machine learning models. You can just use these services to give in proper input and get the results immediately.

Use-Case: Scan documents, identify the texts, and transcribe them to text.

Finally

These were all categories AWS Amplify supports. You can build so much stuff with these categories. If some categories are not supported (e.g. SQS → Please Amplify 🙏🏼) you can simply add them by adding CloudFormation templates or looking for community-made plugins.

I've used Amplify already for a couple of projects and have two running SaaS applications on Amplify. If you want to know more about Amplify and building SaaS products on Amplify, follow my Twitter 🙂

What is AWS Amplify? → It is a lot!

Sandro Volpic — Fri, 22 Oct 2021 05:39:43 +0000

What is AWS Amplify? → It is a lot!

AWS Amplify refers to 5 different products. Let's see them!

AWS is not really great with naming things. Nothing new here. Amplify is one of the products where A LOT of confusion exists on which product you are actually referring to. With this post, I will try to give some clarity. I will go through each product Amplify has, what the main purpose is, and how they are connected. Let's go!

TLDR; Basically there are 5 things which are Amplify:

Amplify Hosting: Hosting service with DNS options
Amplify Console: CI/CD for full-stack apps
Amplify CLI: Bootstrap your infrastructure
Amplify Libraries: Connect your app with AWS
Amplify Admin UI: Use AWS without AWS account 🤯

Let's get into some details.

Amplify Hosting

Amplify hosting offers the ability to quickly and easily host your static web page. If you have a react web app and want to host it, Amplify hosting is the way to go. Some really great features are:

Continuous Workflows:

Amplify Hosting is deeply connected with Amplify Console (CI/CD) which we cover in the next part. After the website is built it can be automatically published and hosted.

PR Preview:Amplify Hosting allows you to preview new PRs in a completely own environment to test out new features

Custom and not custom domains:Amplify Hosting published your web page normally on some Amplify domain such as develop.d23z478fg.amplifyapp.com. This is done automatically. If you want to map custom domains you can easily do this.

SSL Certificate includedSSL is automatically included in both custom and not custom domains.

MonitoringYou can monitor the metrics of the application and get SNS notifications in case you reach certain thresholds. Under the hood Amplify Hosting uses S3 and CloudFront to deliver your webpage over the globe. It abstracts the hassle of setting everything up manually and gives you a lot of options to customize the experience.

Amplify Console

Amplify Console is the CI/CD component of Amplify. It allows you to build full-stack apps by building your backend, frontend and deploying all of it with Amplify Hosting.

The console follows a git-based workflow. That means it will automatically be triggered by pushes or PRs on your git branches. The console build is based on a docker image which you can adjust to anything you want. After setting the image you can define your build in the build.yml file and follow several phases. The phases are:

Provision: All AWS resources for the build will be provisioned
Build: Backend and frontend deployment
Deploy: Everything will be deployed.
Verify: Tests will be executed

After deploying the website a preview is available to check how it looks like.

Amplify CLI

The Amplify CLI is one of these products which are normally meant if people talk about Amplify. A CLI is a command-line-interface, so a program you can execute just in the terminal without a GUI. The main idea of the CLI is to make the experience of programming fullstack apps on AWS a lot easier. The CLI handles a lot of things, but mainly it is doing the following:

Provisioning resources by creating CloudFormation templates for pre-defined categories
Deploying resources and updates (e.g. for lambdas)
Generating boilerplate templates (e.g. VTL for GraphQL)
Lokal mocking of some resources such as API, Lambda, DynamoDB

With Amplify you can easily add several services by following a wizard-like approach and Amplify will create the CloudFormation stacks you need for getting the resources.

The CLI is doing quite a bit of magic to give you your desired services. I think it is an awesome product to use but be quite aware that you can run into some bugs where you maybe need some support.

Amplify Libraries

Amplify also offers libraries for connecting your app with AWS services. Currently, the libraries are available for the following platforms:

JavaScript
iOS
Android
Flutter

Be aware that for all other platforms you can also use the main SKD of AWS. Amplify is trying to make things easier for you but if it is not available use the SDK.

The libraries let you connect the backend and frontend with the categories which are available in Amplify such as Authentication, DataStore, API, etc.

Amplify Admin-UI

The Admin-UI is one of the latest products.

The idea is to create an app backend with a much nicer and cleaner interface compared to the typical AWS console. It also allows you to access AWS resources without using an AWS account. That means no handling of IAM policies and users. Just the first deployment of the backend needs an AWS account but after that, you can invite team members to the Admin-UI without an AWS account.

It also allows you a visual data modeling approach. That means you can see how your data model interacts with each other and how the relationships look like. The really neat thing is that all configured resources you provisioned with the Admin-UI are also available in the CLI. So it is a great way of working together.

Anna is the main PM of the Admin-UI and loves to improve the product, so if you want to help her, reach out to her 🙂

Anna M. Pfoertsch 🍌🥨

@_pananapread

Learning from documentation is cool, but I want to hear from some users! 🤩 If you use @AWSAmplify and have some thoughts to share, I would love to chat ✌️

18:17 PM - 17 Jun 2021

That's it! These are all Amplify services. I hope it will be easier for you now to know what services are doing and how they interact. If you want to know more about Amplify follow my Twitter you can also see it as a Thread 😉

Sandro Volpic

@sandro_vol

AWS Amplify refers to different products.

You are confused what Amplify exactly is?

We know that AWS isn't the best with naming its products so let's see what Amplify products are exactly out there.

1/6

08:04 AM - 28 Sep 2021

The Mom Test - How to talk to customers. A Summary

Sandro Volpic — Fri, 22 Oct 2021 05:37:22 +0000

The Mom Test - How to talk to customers. A Summary

Have good customer conversations and validate your ideas.

"The Mom Test, How to Talk to Customers & learn if your business is a good idea when everybody is lying to you" by Rob Fitzpatrick is a book with the aim of improving your customer conversations and getting real learnings out of them! The idea behind the title is that you shouldn't ask your mum if your idea is a good idea because she will lie to you. Like you will learn in this book most people will lie to you, not even with evil intent. Unfortunately, this will not help you with validating your idea.

The book tries to teach you how to get out of these lies and start a conversation where you actually learn something. The main takeaway is to validate the problem and not the idea. Start conversations that focus purely on the customer's life and the problem.

This is a summary of the book with some quotes and the most important learnings I could gain from it. I list the table of contents and go through each chapter. If you want to learn more about it give the book a deep dive.

TLDR

Don't talk about your idea
Let the customer talk
Talk about the problem

The Mom Test

In the chapter The Mom Test the interesting part begins. Rob shows you a really common scenario on how a bad validation conversation looks like. It starts with the so-called Mom Test. A son wants to test his idea on his mum and asks her a couple of questions. Since the mum doesn't want to hurt the feelings of the son she "validates" the idea for him and tells him that it is really awesome. It follows a second conversation that focuses purely on the problem the idea wants to solve (digital recipes). With that approach, the son has some success, by focusing on the mum, her iPad, and cooking skills instead of pitching his idea.

There are three main points to follow the mom test's approach:

Talk about their life instead of your idea

Ask about specifics in the past instead of generics or opinions about the future

Talk less and listen more

There are some examples of good and bad questions. Take them with a grain of salt, but the overall idea of the questions is the same. Focus on the customer's problem.

Good questions:

Why do you bother?
Talk me through your workflow
What else have you tried?

Bad questions:

Do you think it's a good idea?
How much would you pay for X?
Would you buy a product which did X?

You see a common rule here. The good questions focus on the customer's life and problem and how he will deal with it. The bad questions focus purely on your idea.

One important question for me is always to ask What else have you tried?

If somebody is complaining about a huge problem that he is so annoyed by but never looked for a solution, the workaround is maybe not worth it to pay for another product. If you see this pattern in several customer conversations it will be hard to sell your product if nobody even is looking for a solution.

If they haven't looked for ways of solving it already, they're not going to look for (or buy) yours.

Avoiding Bad Data

The second chapter is Avoiding Bad Data. Bad data refers to everything where you think you are learning something but you don't. They are also called false positives.

There are three types of bad data:

Compliments

Fluff

Ideas

Compliments

A typical conversation with bad data looks like that:

You: (end of the pitch) .. and that is why you need my product.

Them: Sounds awesome!

You: Yes it is it will save your business.

Them: Really, really cool.

You go back to your team and say the meeting was awesome, they love it and it is definitely a proper validation. But really is it? They said they like it but it is nowhere a real validation if it will save any problem. Of course, compliments are good, everybody likes them. They prosper your motivation and it can be true of course that people like your idea. However, it is still not a validation. If you get compliments, Rob suggests doing the following:

... try to get specific. Why did that person like the idea? How much money would it save him? How would it fit into his life? What else has he tried.

This again goes back to the problem, his life, and his approach to solving it.

Even if you like compliments, they are just bad data and you have to avoid them. Often there is another way around, so that founders are fishing for compliments. Compliments are no learning. It is just unnecessary time wasted with a potential customer where you really could learn about solving his problem.

Fluff

Fluff is a special one. It basically refers to useless information. Customers will tell you a lot if you ask the wrong questions. One example from the book is:

You: "Do you ever X"?

Them: "Oh yeah all the time."

That is not validation that the problem really exists. From here it is important to zoom in and get details. How does it happen? What is the workflow behind it? What else have you tried? I think you see the pattern...

Ideas

The last type of bad data is ideas. And that is really interesting to see.

Entrepreneurs are always drowning in ideas. We have too many ideas, not too few. Still, folks adore giving us more.

The main issue here is that everybody has ideas and most of the people are so convinced that their idea is just the best one. So, it often happens that customers start pitching their ideas. In terms of a software business, these ideas are often feature requests for your own product. Now, that is an essential part. You have a customer who likes your product and wants to improve it for his workflow of working with it. You have to go into this feature request and analyze it. But you don't have to go to your computer and start implementing it! Validate the idea or feature as well by talking about it. Maybe you find an underlying issue. Maybe your product is already able to do it in a much nicer way but you failed in explaining. Understand the why. Understand why your customers want this feature and the root cause behind it.

Rob again gives us some awesome and really basic questions for that:

Why do you want that?

What would that let you do?

How are you coping without it?

How would that fit into your day?

Tips

At the end of the chapter, Rob gives you some general tips.

Let the customer talk more than you do
Don't mention your idea because then they start to protect your idea
Don't fall into pitch mode

Asking important questions

You need to focus on asking important questions and not just random ones. Important questions vary from one idea and problem to another. But basically, you have to focus on two things.

Find the bad news

Ask all questions which can be bad news and showstopper and ask them. Not starting something because you know it won't work is great learning. If you build a stock analyzer app but nobody will enter his financials because of security reasons, this is a show stopper!

Don't focus on details too much

Don't focus on unimportant details of your problem. Focus first on the general problem and if it exists. If it does start digging deeper and zooming more into it. Start general and zoom in.

Prepare your list of 3

Rob also suggests creating a list of the 3 most important learning you need. They can (and often need to be) different for the different stakeholders. Keep them always ready that you can ask your potential customer at every given time.

Keeping it casual

Keep it casual and don't make it overly professional just because you're talking about business. The main thing you want is a casual talk with another person about some problem. The best case is if the person doesn't even know that this is a discussion about some business and especially a business you want to build something for.
You don't have to set up official meetings, send out several reminders and show up in a suit. Try to be a normal human being and have a normal, but interesting conversation. These meetings often occur not even in a planned fashion. If you meet an industry expert at a party and you have your list of 3 questions ready you can just start right in and talk to him.

Commitment and advancement

Of course, at some point, you have to start talking about your solution and idea. This now brings us in danger that oftentimes the learning is over because we receive compliments, fluff, and just bad data in general. The great thing is if we know about that we can cut right through it and find the real meaning behind it. What you want to accomplish now are commitments and advancements of your customer. So after your pitch try to get a commitment or some advancement. Rob defines them as:

Commitment: They are showing they're serious by giving up something they value such as time, reputation, or money

Advancement - They are moving to the next step of your real-world funnel and getting closer purchasing

If you sell a SaaS product to a company and had the learnings and your pitch you now want to sell it. If you have meetings without any action points or commitments at the end you are often in the trap of an endless meeting circle. Try to get action points for the next meeting. If they don't want to settle on anything, use this as a learning and cancel this customer because he is often a dead end. But you also need to give them a concrete chance to buy or reject you. Don't hesitate to ask and give them different options for buying. If they won't commit to anything you can also get advancements such as introduction to other companies, teams, or industry experts. But if everything ends with fluff or compliments, really think about it if you should continue or not. Your time is not endless.

Rob gives some good examples for good or bad meetings:

Good

"There are a couple people I can introduce you to ..."

"What are the next steps?"

"Can I buy the prototype?"

Bad

"That's so cool. I love it"

"Looks great. Let me know when it launches."

"I would definitely buy that."

Good endings are with immediate actions, bad ones are just compliments and fluff.

Finding conversations

Now you know everything about talking to your customers. But how do you find them? There are several options to find them:

Cold calls: Cold e-mail or call random people and ask if you can talk to them.
Use random situations: You are at a party and hear that somebody is complaining about your problem? Talk to him and ask some questions.
Use an excuse: Be a bit sneaky and don't talk about your goal instead find an excuse to talk about another issue and slight slowly into your conversation. Do you want to talk to an investor about your stock analyzer? Maybe ask about some stock tips.
Go where your customers are. You want to build something for a specific group like crypto traders? Go to crypto meetups!
Landing Pages: Launch a landing page and try to get as many conversations started as possible. If somebody is singing up talk to them!

You can do it also the other way around. Bring the customers to you:

Organise meetups: Meetups are an easy way for finding customers & gaining instant credibility.
Speak & Teach: If you're a good speaker you can find many customers as well.
Industry blogging: If you blog in that certain industry you can find a relevant audience and talk to them.

Most of these customers will be cold-called above. They often don't know you (except for your online presence). Normally, you get way better results if you get a warm intro. Try to get introduced to many people by:

Ask your friends. You need a certain contact, just ask if anybody knows anybody in this area.
Industry advisors. If you have any former advisors or mentors ask them to help you.
Universities. If you're still a student ask your professors. Professors have endless contacts to the industry
Investors. You can ask VCs or smaller investors for some contacts in this area.

Framing the meeting

Now you have the skills to talk to the customer and found the customer. How do you want to frame the meeting now? We already saw that we should keep it casual. But we also want to have an efficient meeting and don't waste the time of the customer. The format Rob suggests looks like that:

Vision / Framing / Weakness / Pedestal / Ask

You want to solve problem X with your vision Y
You are currently in stage XYZ (prototype on an app)
Show your weakness and why you need help
Show why they can help (research them before)
Ask for explicit help

If possible do your meeting in person.

Choosing your customers

You often find yourself having too many different options, ideas, and customers to focus on. You need to focus on specific ones. This is possible with different mechanisms:

Customer segmentation: Segment your customers by finding consistent and common problems and goals they have.
Customer slicing: Slice your segment into smaller groups. Look at the subsets and the commonalities and differences. If you find them put them into another sub-group.

Running the process

Now we have everything. We know how to talk to customers, we know how to find and group customers. Now we just have to execute it. The one really important part here is that just because you are the business guy or just because you read the book it is not a good idea to do the whole process by yourself. You should communicate with your team, ask them what learnings they need and focus on three main learnings for each group. If one person is just talking to the customer he has the ultimate product decisions because he can always vouch for the customer's perspective. That is why the whole learning should be shared in the most transparent way. The best one would be recordings but often that is not really suitable. The most suitable way is to take detailed notes and talk them through right after your talk.

So you need some pre-, and post-processing of your work. You need to start with your list of the big 3 learnings and end with the analysis of your notes. But if you don't know what you want to learn from the beginning, you should not have the conversation in general.

Rob also gives some suggestions on how to take notes, use smileys to make the process faster, and focus on also looking at the notes.

Conclusion

That's it! That is the whole Mom Test. It covers on the one-side really the basics of customer conversations and on the other side surprises with a lot of obvious things which tend to happen a lot (e.g. looking for compliments). The book contains several great examples which I did not cover here. If you want to dig deeper I really recommend reading the book. It is not super long (~140 pages) and is really worth it. Rob did an awesome job here!

In the conclusion, Rob also focuses on telling you that not everything will be perfect. You still will ask dumb questions, look for compliments and just talk about yourself. And that is okay. If you learn from that and try to do it better. To finish with his final quote:

It's going to be okay.

If you want to see The Mom Test in action and see how I use this book to build my Saas product, follow me on Twitter

How to develop a Serverless Chatbot with AWS Amplify, Amazon Lex & React

Sandro Volpic — Wed, 01 Sep 2021 06:06:40 +0000

How to develop a Serverless Chatbot with AWS Amplify, Amazon Lex & React

Create your chatbot, step-by-step. Code & Architecture inclusive.

This blog post gives you an introduction and step-by-step guide on how to create a chatbot application with AWS Amplify & AWS Lex. The great part about using this tech-stack is, that no Data Science or NLP knowledge is required because it is purely created with managed services by AWS. The same technology is used within Alexa so it is a bulletproof stack.

In this post, we will create a chatbot for booking a car. You can find the code here.

Let's go!

The Architecture

Let's start with the architecture.

The architecture contains four different components:

Web Interface - Chatbot Component

The web interface is a Single Page Application (SPA), built with React & TypeScript. This gives us the opportunity to host the application in a cheap way and serve it very fast to users all over the world. We can also use already existing libraries (such as the chatbot implementation from Amplify) and we don't have to reinvent the wheel.

AWS Amplify

In this application, Amplify is used for two different use cases.

Amplify-CLI for bootstrapping the cloud environment and building the infrastructure as code
Amplify JS libraries for accessing AWS components and building the chatbot interface.

The web application is hosted via Amplify which uses S3 and CloudFront in the background. The chatbot and lambda function is created with Amplify.

Amazon Lex

Amazon Lex is the chatbot interaction service by AWS. It is the same service that uses Amazon Alexa and is built to serve many customers.

AWS Lamdba

Lambda is the serverless function service by AWS. For this use case it is optional. But normally it will be used to extend the functionality of chatbots by adding more business logic to them. For example for really booking an Uber.

You can see the architecture is really simple and just consist of 4 different parts.

Let's Code!

Now let's create the actual chatbot application. If you don't have already, please install the Amplify CLI, see this guide.

Prerequisites for this project are:

Amplify-CLI
yarn or npm
npx
AWS Account

Project Setup

React App

First of all, let's start with the initial project setup and folder structure. Go into the folder where your project should reside and type in the console:

npx create-react-app chatbot-with-amplify --template typescript

This bootstraps the initial folder structure with TypeScript as the main language.

Amplify App

Now, we will do the same thing for Amplify. Just run amplify init within your newly created project folder and follow the CLI commands.

cd chatbot-with-amplify
amplify init

CLI Workflow:
You can use the default values almost everywhere.

? Enter a name for the project chatbotwithamplify
The following configuration will be applied:

Project information
| Name: chatbotwithamplify
| Environment: dev
| Default editor: Visual Studio Code
| App type: javascript
| Javascript framework: react
| Source Directory Path: src
| Distribution Directory Path: build
| Build Command: npm run-script build
| Start Command: npm run-script start? Initialize the projectwith the above configuration? (Y/n) YUsingdefault provider  awscloudformation
? Select the authentication method you want touse: (Use arrow keys)
❯ AWS profile
  AWS accesskeys

Here, you must choose your authentication method (either profile or access keys) and hit enter. I always suggest using AWS Profiles for your different accounts. Here is a short explanation of how to create them. After choosing it your Amplify project was created within the directory amplify.

Sample Chatbot

Now we will build the actual chatbot component. Amplify has its own category for chatbot called interactions. We start by using a pre-defined chatbot template for booking different trips.

First, we start by adding an interaction component.

amplify add interactions

We have to configure a bunch of different stuff, just follow along the output here.

? Provide a friendly resource name that will be used to label this category in the project: (lex282f4c21) lex282f4c21
? Would you like to start with a sample chatbot or start from scratch? (Use arrow keys)
❯ Start with a sample
  Start from scratch
? Choose a sample chatbot: (Use arrow keys)
❯ BookTrip
  OrderFlowers
  ScheduleAppointment
? Please indicate if your use of this bot is subject to the Children's Online Privacy Protection Act (COPPA). No
Successfully added resource

We will start with the sample chatbot BookTrip. After adding this resource we will push it to AWS. The push command shows us a quick overview of all components to add.

amplify push

Output:

✔ Successfully pulled backend environment dev from the cloud.

    Current Environment: dev

┌──────────────┬─────────────────┬───────────┬───────────────────┐
│ Category     │ Resource name   │ Operation │ Provider plugin   │
├──────────────┼─────────────────┼───────────┼───────────────────┤
│ Auth         │ cognito8550b67d │ Create    │ awscloudformation │
├──────────────┼─────────────────┼───────────┼───────────────────┤
│ Interactions │ lex282f4c21     │ Create    │ awscloudformation │
└──────────────┴─────────────────┴───────────┴───────────────────┘
? Are you sure you want to continue? (Y/n) Y

In the overview we see that Amplify added one new Interaction component lex282f4c21 and one Auth component which acts as the authentication method for the bot. After hitting enter the CloudFormation templates will be executed and deployed on your AWS account.

You can now open the service Lex and see your newly created chatbot named: BookTrip_dev.

This is how the chatbot overview looks like. We will go through the different parts you can see here:

Intents

On the far left side you can see the different intends. We have two:

BookCar_dev
BookHotel_dev

One chatbot can have different intents it can serve. We will just look at BookCar_dev.

Sample Utterances

Utterances are sentences or words on how to trigger a specific intent. In the case of the BookCar chatbot these utterances are:

Book a car
Reserver a car
Make a car reservation

Slots

Slots are data points that have to be collected by the user. In the example of booking a car, we need different information like the time, date and type of the car. The slot has different attributes like:

Priority: The order of the slot
Required: Do we need this slot or not?
Slot type: What type is the slot. There are pre-defined types like AMAZON.DATE or AMAZON.TIME which can parse text into date or time. And there are self-defined types like for example the type CarTypeValues. These were defined in the template and can be seen on the left side under SlotTypes.
Prompt: What is the question to show the user for receiving the slot as an answer?

Confirmation Prompt

This is the final confirmation of the chatbot conversation. In this example, it is a summary of the whole car reservation.

Testing the chatbot

You can test your chatbot by clicking on TestChatbot on the right side of the window. A chatbot window pops up.

This is really helpful because while you enter your messages and receive responses you see the filled Slots. The great thing about the pre-defined slot types is that AWS parses for example dates that are hidden in text into proper date formats. If I answer the question What day do you want to start your rental?, with Tomorrow it parses it to the correct date.

Chatbot information in Amplify

All this was created by the sample defined in Amplify. Since we are using Amplify as Infrastructure as Code (IaC), this can be defined as code. If you take a look at your project in the file amplify/backend/interactions/lex282f4c21/lex-params.json you will see all parameters in one JSON file.

{"resourceName": "lex282f4c21","intents": [
        {"cancelMessage": "Okay, I have cancelled your reservation in progress.","confirmationQuestion": "Okay, I have you down for a {CarType} rental in {PickUpCity} from {PickUpDate} to {ReturnDate}. Should I book the reservation?","slots": [
                {"name": "PickUpCity","type": "AMAZON.US_CITY","prompt": "In what city do you need to rent a car?","required": true,"customType": false },
              ...
            ],"utterances": ["Make a car reservation","Reserve a car","Book a car" ],"intentName": "BookCar","newSlotTypes": [
                {"slotType": "CarTypeValues","slotTypeDescription": "Enumeration representing possible types of cars available for rental","slotValues": ["standard","full size",
                       ...
                    ]
                }
            ]
        }
    ],"outputVoice": "Matthew","botName": "BookTrip","coppa": false}

With these parameters, your can adjust and customize your chatbot in any way you want 😉

Interaction Component

The next step is to have a Chatbot component in our own web application. For that, we open the react project in our favorite IDE (probably VSCode) and add a new folder components and chatbot and install @aws-amplify/ui-react for using the pre-defined UI libraries. After that, we just start the development server.

cd chatbot-with-amplify
code .
mkdir src/components
mkdir src/components/Chatbot
touch src/components/Chatbot/Chatbot.tsx
yarn add aws-amplify @aws-amplify/ui-react 
yarn start

In the Chatbot.tsx file we return the AmplifyChatbot component and connect it to our chatbot. The whole file can be seen here.
.

&lt;AmplifyChatbot
    botName="BookTrip_dev" botTitle="This is a chatbot made with Amplify" welcomeMessage="Hi! I was made with Amplify. How can I help you?"/&gt;

This renders the whole component of the chatbot and we can already speak to it like in the Lex interface. Just go to your src/App.tsx and add the Chatbot and you should be able to see it. See App.tsxhere :

App.tsx

functionApp() {return &lt;Chatbot /&gt;;
}

If you open your browser and head to http://localhost:3000/ you can see your chatbot app and interact with it.

After finishing your conversation you can check the console in the browser and find the filled slots:

{"slots": {"CarType": "luxuery","DriverAge": "21","PickUpCity": "Munich","PickUpDate": "2021-09-01","ReturnDate": "2021-09-02" }
}

Finished 🥳

That's it! That is the whole workflow for building a chatbot. In this use case, we've used the easy approach of building a sample chatbot. The workflow is almost the same for building one from scratch. In one of the next posts, I will show you how to do exactly that.

If you want to know more about AWS, serverless, and bootstrapping your product on AWS follow my Twitter.

How to develop a serverless mobile app with Amplify, React Native & GraphQL

Sandro Volpic — Tue, 10 Aug 2021 12:26:48 +0000

This post will show you an introduction to the architecture of a cross-platform (Android & iOS) mobile application. The app was built with React Native, Amplify, and GraphQL. I'll take my own application deopsur as an example and explain all services and components based on this application. Deposur is an app for tracking your portfolios and investments.

Let's first talk about why serverless and cross-platform.

Why Serverless?

First of all, let's talk about why to develop an application serverless. These are the main reasons:

Sandro Volpic

@sandro_vol

Why develop you SaaS product serverless?

🧷 Less risk: If nobody uses it → You won't pay anything
⬆️ Scalable: If many people are using it your infrastructure scales
🔒 Secure: Let AWS secure your environment, sorry but they are probably better 😉

13:11 PM - 27 Jun 2021

I could go on with potential benefits such as development time, costs, etc. but I think many of you know these benefits already.

Why cross-platform.

Cross-Platform development means that you render two native apps from just one codebase. This brings the main benefit that you just have to maintain and test this codebase. Of course, sometimes there are situations where you have to distinguish between both, for example in terms of styling, but this can be easily done.

The Architecture

Let's go over the architecture. I will explain the technologies, services, and components I used and why I used them. I separate the architecture into frontend and backend.

Frontend

The frontend tech-stack has the following components and technologies:

React Native
TypeScript
react-native-elements
Apollo (GraphQL)

React Native

React Native is an open-source framework, originally developed by Facebook for creating cross-platform applications with JavaScript. The main difference to other cross-platform technologies such as Cordova or Ionic is that the apps will not just be rendered in a web browser, but instead will be a proper native application. To have the same experience as with native applications, some customization for both platforms has to happen.

TypeScript

React Native and its libraries are almost all supported in TypeScript. TypeScript is an additional layer to JavaScript built by Microsoft to have type-safety in your JavaScript code. The number one reason for using TypeScript is developer experience. This reason is often overlooked but it is so important to know which types you're passing around in your code. Especially, in the combination with GraphQL, it is really awesome to know which kind of data you will receive with which requests.

react-native-elements

react-native-elements is an UI component library. It offers you customizable assets which you can reuse throughout your app. It implements the Material Design that is really popular in Google applications.
There are many component libraries out there, we built the first version of Deposur with UI Kitten but quickly switched back to react-native-elements for the theming and component implementation.

Apollo

For managing the internal state of the app we use Apollo in combination with AppSync and GraphQL. Apollo caches all queries and normalizes them by a key schema we define at the initialization of our app. It reduces the boilerplate and the complexity of using state management libraries such as Redux. It has some awesome capabilities like defining how to cache the data (network, local, etc.), when and how to refetch queries, and updating local data for optimistic mutations.

Backend

Since this article is talking about building a serverless app, let's dive into the backend part. The main idea you want to focus on when building serverless is to not managing any infrastructure by yourself. Use as many managed services as possible and just take care of your business logic.
The following parts will be separated into the different AWS services I'll recommend for building this kind of application.

Amplify

Amplify can be distinguished into three different services:

Amplify-CLI: Infrastructure as code and graphql-transform
Amplify-Console: CI/CD pipeline
Amplify libraries: Frontend libraries for accessing AWS services.

I recommend using all three but this section is focused on the CLI.

Infrastructure as Code

Amplify-CLI gives you the opportunity to bootstrap your cloud environment with a few CLI commands and it creates CloudFormation templates for you automatically. This is also called Infrastructure as Code (IaC).

For example, if you type in:

> amplify add storage
? Please select from one of the below mentioned services:
> Content (Images, audio, video, etc.)
  NoSQL Database
? Please provide a friendly name for your resource that will be used to label this category in the project:
> dynamodb
? Please provide table name:
> tablename

Amplify creates several CloudFormation templates for the database, IAM permissions, etc.

GraphQL Transform

The main benefit of using Amplify is the graphql-transform library. It gives you the opportunity to annotate your graphql.schema with annotations such as model, connection, searchable, or auth for adding certain functionality and components to your architecture.

Take for example this schema:

type Holding 
  @model 
  @searchable
  {
  id: ID!
  ISIN: String!
  currentPrice: Float! @funtion(name: priceResolver)
}

The model directive adds a DynamoDB table of the type Holding to your backend. Also, it adds an ElasticSearch Service and streams all data to this instance. The field currentPrice will be resolved by a lambda function called priceResolver.

Deployment

Amplify also takes care of the deployment of all CloudFormation templates. This can be sometimes a headache (hello nested stacks) but in general, it takes away a huge burden. It also manages the deployment to different stages such as development, staging, and production.

If you start building your serverless app I highly recommend checking out Amplify because it is an awesome project, has a great community, and gives you some really cool tools at hand for building your full-stack application. Be aware that some magic is happening in the background.

AppSync

AppSync is the managed GraphQL API by AWS. It is one of the most unique services AWS offers in the serverless area. AppSync allows you to use almost any data source you want and map it to certain types. First of all, you need to define your GraphQL schema. We take the same one we saw before.

type Holding 
  @model 
  @searchable
  {
  id: ID!
  ISIN: String!
  currentPrice: Float! @funtion(name: priceResolver)
}

Note: This is not a valid AppSync schema but a valid Amplify GraphQL schema.

Since we are using Amplify in combination with AppSync we can use these directives. We already mentioned that the field currentPrice will be resolved by a lambda function. In general AppSync fields can be resolved by one of these two methods:

VTL Templates: Velocity Templating Language. This is a templating language developed by Apache which is not completely straight forwards.
Lambda Resolvers: You can use lambda functions for returning your fields.

Amplify automatically generates VTL templates for your DynamoDB fields, for lambda resolvers you have to add the lambda function to your project and return the attributes you defined.

Query, Mutations, and Subscriptions

This is not a complete GraphQL introduction. But in general, you can either query, mutate or subscribe your data.
A query looks like that:

query MyQuery {
  getHolding(ISIN: "DE0005190003") {
    ISIN
    currentPrice
  }
}

And it returns a JSON object:

{
  "data": {
    "getHolding": {
      "ISIN": "DE0005190003",
      "currentPrice": 90.94999694824219,
    }
  }
}

A mutation looks similar, just that you often have an input object which you have to pass.

Benefits

We only use AppSync and GraphQL in our API for all data. There are two main benefits involved:

Frontend gets the power

The frontend gets the power of fetching exactly the data it needs. There is no over-, or underfetching in GraphQL. You just get the data you specify to get.

State management

With GraphQL & Apollo, it is fairly easy to manage your state and cache in your app. You begin by normalizing your keys for the types in your schema and have them in your in-memory-cache.

Lambda

Lambda is the most known serverless service of AWS. As already mentioned in AppSync, lambda is purely used for our business logic as AppSync resolvers. Lambda executes your code without ever thinking about hardware. The main configuration is the memory setting which should always be maximized a bit to ensure fast execution.

We follow the approach of having one lambda function as a resolver for all AppSync fields and Lambda layers for handling the dependencies.

The Lambda resolver is responsible for the following things:

Getting the live price from a third-party API
Getting historical prices from a third-party API
Doing aggregations of the data
Calculate different indicators such as the average buy-in price, invested capital, etc.

This is the main use case of using Lambda here. There are also some minor use cases such as payment webhooks, newsletter campaigns, and monitoring services but the resolver is our main business logic.

DynamoDB

DynamoDB is an amazing service. It is a fully managed NoSQL database by AWS. In combination with GraphQL, Amplify, and AppSync it works really well. Basically, it is a key-value database with JSON-like objects.

All our DynamoDB tables come directly from our GraphQL schema. Amplify creates them automatically. We mainly access DynamoDB via VTL resolver from AppSync or our Lambda resolver for aggregating and mutating data.

ElasticSearch

The last data source we use is the full-text search engine elastic search. It integrates really smoothly with using Amplify and all data gets streamed into elastic search automatically. You can query your data and execute searches with GraphQL as well. AppSync maps them via VTL resolvers. You can use different search operators such as eq, ne, matchPhrase, and many more.

It is really powerful, but unfortunately also the most expensive piece in this architecture. Since elastic search is not serverless it is an instance that runs 24/7. Take this into consideration and think about it to use it or not! If you don't have a complex search use case try to use smart access patterns within your DynamoDB and use them as an initial search.

Cognito

Cognito is the authentication service in AWS. I (and many others) would always recommend never building certain systems by yourself. One of them is an authentication system. Arvid Kahl proves my point here as well:

Arvid Kahl

@arvidkahl

Don't build this yourself: Authentication Systems.

Why? Because you won't make it reliably secure. It'll be complicated and not extensible.

Most importantly: it's not a core feature of your unique solution to your customer's critical problem.

thebootstrappedfounder.com/not-in-house-o…

12:04 PM - 30 Mar 2020

Cognito takes this burden away. It offers a sign-in and sign-up functionality even with a pre-defined hosted UI for signing up which you can integrate with no effort.

The main benefit is to use social-sign-in functionality within your app. By using these features you give your users the opportunity to log in seamlessly with just one click.

Cognito supports the following social sign-in provider:

Facebook
Google
Apple
Amazon

Also, all functionalities like changing your password, resetting your password, etc. are supported natively by Cognito and you don't have to build it yourself.

Firebase Analytics

The last service I show you is not from AWS but from GCP. Indeed, I thought about this a lot, but Firebase Analytics is just working way better and nicer compared to AWS pinpoint. Not just the UI is nicer (that is almost always the case if you compare GCP to AWS) but also the functionality is way better to incorporate into your mobile app.
I recommend using react-native-firebase for integrating Firebase into your app.

Costs

One word about costs. Using this architecture as your app backend with an initial low number of users will cost you about nothing if you do not use elastic search.

If you use the smallest elastic search instance it will cost you about 20€/instance/month.

All other components will be completely in the free tier and just be billed on demand. That means if you really just have a low number of users it won't cost you anything. This reduces the risk immensely. If it starts to cost you money, or if you need a full-text search you can always apply for the activate program and get 1000$ in credits for free.

Conclusion

In this article, I showed you how an example serverless architecture for a cross-platform mobile application looks like. By learning this architecture you can apply it for so many different use cases. You are of course not restricted to mobile apps only, instead you can use it for all full-stack applications.

Of course, we somehow cheat by using Amplify here but this really helps with building up your infrastructure in a fast and secure way.

If you want to see more on building & bootstrapping serverless applications, follow my Twitter 🙂

Thanks!

Top 5 Serverless AWS Services founders & Indie Hackers should know

Sandro Volpic — Fri, 06 Aug 2021 07:28:27 +0000

The goal of this article is to introduce you to the top 5 serverless AWS services which I think every tech-founder or Indie Hacker should know. This is not a deep dive on these services and I want to explain them in a high level fashion and tell you why they are worth using and learning. With these services you are able to build almost every web- and mobile application you can think of. Almost all high level programming languages such as Python, TypeScript, JavaScript and Java can be used with these services. So, let’s jump straight in.

Amplify CLI

I start with the obvious one, Amplify. Important to note is, that there are two (almost three) “services” called Amplify within AWS. We have to distinguish between:

Amplify CLI: Bootstrap your backend
Amplify Libraries (e.g. JS libraries): Frontend libraries for accessing AWS resources
Amplify Console: CI/CD pipeline for frontend and backend

We talk about Amplify CLI here. With the Amplify CLI you are able to bootstrap your backend with a few commands within the Command Line Interface. Amplify has several categories you can add, for example these are:

API: AppSync GraphQL or REST API Gateway
Authentication: Cognito
Storage: DynamoDB, S3
Functions: Lambda
Hosting: S3 & CloudFront

With a few commands you are able to build fullstack applications with a guided CLI.

The main benefit in my eyes is the graphql-tranform library. This library enables you to create your data schema with custom annotations like model or connection and the library transforms this schema to a valid GraphQL schema and at the same time creates CloudFormation templates for creating your backend resources such as DynamoDB tables, Cognito connections, etc.

Take this schema as an example:

type Holding @model {
  id: ID!
  ISIN: String!
  currentPrice: Float! @funtion(name: priceResolver)
}

It creates the type Holding. The model annotation creates a table in DynamoDB with id as the primary key. currentPrice will be resolved by the lambda function priceResolver.

The *main drawback * in my eyes is that you are not as flexible as with building up your infrastructure with a typical IaC solution like CDK or Terraform. Since a lot of magic is happening with Amplify you will likely run into some issues, especially when you are working with several team environments and lambda layers.

Nevertheless, it is a great tool, it has a great community and the team is still developing the services further. The backend of deposur was completely bootstrapped with Amplify. If you want to learn one service, learn this one!

AppSync

This brings us to the next service, AppSync. AppSync is a fully managed GraphQL API by AWS. GraphQL enables you as a developer to get exactly the data you need without worrying about fetching too much or too less data overfetching & underfetching). In general you have three main functions within AppSync. These are Queries, Mutations and Subscriptions.

With Queries you can query data from different data sources. That means that you can have a type Holding for example which gets data from different sources. Lets take our example schema again:

type Holding @model {
  id: ID!
  ISIN: String!
  currentPrice: Float! @funtion(name: priceResolver)
}

The attribute ISIN is a string which comes from DynamoDB, the currentPrice gets resolved by a Lambda function called priceResolver. Lambda resolvers give you the main flexibility here. In the lambda function you can have as much customised code as you need (request two different APIs, clean & preprocess data, …) and respond with exactly this data you need in your application. It doesn’t matter where your data lives, AppSync gives you the opportunity of resolving it under one hood for the application. This is a great deal of flexibility.

You can query your data then with:

query MyQuery {
  getHolding(ISIN: "DE0005190003") {
    ISIN
    currentPrice
  }
}

And it returns the following code:

{
  "data": {
    "getHolding": {
      "ISIN": "DE0005190003",
      "currentPrice": 90.94999694824219,
    }
  }
}

With Mutations you can change your data and update it. Subscriptions give you the ability to live update your data.

Why to learn AppSync as a founder?

Why should you learn AppSync as a founder? First of all you get the main benefit of using GraphQL which is working with type safety and giving the frontend developer the power of requesting exactly the data it needs. Secondly, you have so much flexibility by connecting every data source you need. Third, you let AWS doing most of the work. You have one single endpoint and no hassle with parsing requests and connecting different AWS services together. It will reduce your development time immensely.

Lambda

Now let’s go back to the roots, Lambda. Lambda is the most common known serverless service. When people talk about serverless many people just refer to lambda. The basic idea behind the lambda service is to run your code without ever thinking about infrastructure. AWS’s promise is just that your code will be executed. Lambda supports several runtimes such as Python, JavaScript, Java, C#, Rust, Go and many more. One of the latest features is that custom docker containers can be used as a runtime and that pricing happens every millisecond instead of every 100 ms. The maximum runtime of lambda is 15 minutes, take that into consideration when building your application. The only infrastructure setting is the memory setting.

Pricing: Lambda is cheap. The first million requests per month are free. From that point on it will be calculated based on the minutes the lambda runs.

Recommendations:

Always increase memory to about 4 GB, the faster it runs the cheaper it is. There is a great library to test this assumption
Declare all your static variables such as DynamoDb from boto3 outside of your handler function -> Decreases cold starts
Keep cold starts in mind when designing your application. If you need certain response times pre-heat your lambda or provision concurrency before.

Why learn lambda as a founder?

Lambda gives you the ability of executing code without ever worrying about infrastructure. The pricing is really awesome. Your whole application can be based on Lambda. It depends on the use case and the overall architecture (go event-driven!) but most of the applications I know can be easily adopted to several lambda functions. You just pay on-demand, you have small development cycles and the deployment is way easier.

Cognito

Let’s look at Authentication. Cognito is AWS’s service for authentication and authorisation. You can use it for Sign-Up and Sign-In purposes, fine granular user group control and even federated logins such as Facebook, Google & Apple Login. If you start your SaaS business you really want to give users a seamless authentication experience and offer social logins. This is easily possible with Cognito. Cognito differentiates User Pools & Identity Pools.

User Pools: Directory of users with Sign-Up, Sign-In and federated login capability.

Identity Pools: Identity pools are for creating unique identities for users and giving them access to other AWS services. This is needed for example for generating temporary credentials for anonymous users.

For the typical authentication capabilities you will use User Pools.

Pricing: You pay per monthly active users and the first 50k are free!

Why?

Give your users the seamless authentication experience they deserve. With Cognito you are able to do that at any scale. You can customise your Sign-Up and Sign-In pages however you want or you can even use pre-built ones by AWS. With federated logins you are able to offer on-click logins.

DynamoDB

The last service I want to introduce is DynamoDB. DynamoDB is a fully-managed NoSQL database which is highly scalable and highly available. I build almost every use case and project now with DynamoDB and I am a huge fan of it.

The structure of DynamoDB is pretty similar to every other database. You have:

Tables: A table has one or more items
Items: That is a collection of different attributes
Keys: You distinguish between primary and sort keys
Streams: You can have streams for triggering something (e.g. a lambda function) on every update on a table

DynamoDB is basically a key, value database where you can store different datatypes as a value. A value can also be a nested list or nested list of objects (like JSON). A DynamoDB Item looks like that:

{
   "ISIN":{
      "S":"DE0005190003"
   },
   "name":{
      "S":"BAY.MOTOREN WERKE AG ST"
   }
}

The key is the column name (ISIN) and the value is the data type (S: String) with the actual value. The item can also be shown with a typical JSON syntax:

{
 "ISIN": "DE0005190003",
 "name": "BAY.MOTOREN WERKE AG ST"
}

Most SDKs are able to parse them into the correct DynamoDB representation.

DynamoDB has some great features for increasing the performance even more such as Global Tables, DynamoDB Accelerator, Point-In-Time recovery and many more. When designing DynamoDB tables it is always important to keep you access patterns in mind. Rick is doing a wonderful job explaining DynamoDB strategies in this video .

Pricing: Pricing is based on reading, writing and storing data. Again, if you just start out your SaaS product the price is so low that it won’t cost you a Dollar. If you have a predictable amount of read and write requests you can even use provisioned capacity which is even cheaper.

Final Words

Thats it! These are the services you should consider when building your application. All of these services have the great benefit of developing your application in a cloud-native way. These are:

Risk-Free. If nobody uses your app you won’t be charged. That minimises your risk immensely.
Scalable. If you acquire a lot of users AWS will scale with your users.
Secure. You won’t secure your servers and applications as good as AWS engineers do. Concentrate on your business logic and let the boring stuff AWS do.

This was a high level overview of course and was not intended as a deep dive for the single services or to be complete. There are many more great services AWS offers. If you want to know more about building your SaaS service on AWS follow my Twitter !

How you get 1000 $ AWS credits with AWS Activate for your SaaS product

Sandro Volpic — Tue, 22 Jun 2021 06:18:50 +0000

When we started to build deposur it was really important for us to keep our costs down from the beginning on. For that you have basically two approaches:

Keep your cost down (wow!)
You don’t have to pay for the costs (aha…)

Since our app is completely serverless (except fulltext search) the costs are already pretty low. But some still come up. For example our elastic search and some larger data ingestions. Since AWS bills are not completely straightforward it is also a good feeling to know that you have a small money cushion in case you accidently trigger some script which will cost a lot (happened almost once).

In this post I’ll quickly show you how we got 1000 $ AWS credits with the AWS Activate founders program which is exactly for bootstrappers.

What is AWS Activate?

AWS Activate is AWS’s program for Startups and Founders to get started quickly in the cloud. There are two different programs you can apply for. One is for VC backed startups and one is for the typical bootstrapped SaaS founder. I am talking about the second one, for bootstrapped startups.

The prerequisites are really low:

Your startup has to be less then 10 years old
You need a landing page
You need to have an AWS account
You need LinkedIn account(s)

I think landing page is even optional but I would highly recommend it to show what you are planning to do.

How to apply?

1.Sign in to your AWS account and go to https://console.aws.amazon.com/activate/home/#/apply

2.Click on your desired package → Founders package → Get started

3.Check “Apply my credits to this account” and check if you are in the right account 😉

4.Now you will see a form where you have to enter some basic information about your company like

Company name
Company description
Website
Industries (up to 10!)
And some information in which services or areas you are interested in

5.The last step is to complete your team profile. Here, just enter your basic information and I recommend to add the LinkedIn profiles of all founders and team members.

That’s it. Click on submit application and wait for a couple of days and get your 1000 $. For deposur it took about 3 days and everything was set. You will see your credits then either in the Activate menu in your AWS account or in your billing account when you click on credits.

Benefits

Credits

I think the first one is easy. You get money for free. 1000 $ in credits for almost all AWS services. The most important exception is that buying domains is not included.

Support Credits

You get 350 $ in AWS developer support as well. I already had contact with some of them and they are super competent with discussing your architecture, ideas and troubleshoot your problems.

Activate Console

The last part and maybe not the most interesting is that you have access to the AWS activate console with additional information, workshops and tutorials. You also get exclusive offers by certain partners like AirTable, ZenDesk or Jira. TBH I did not use them so far but I am sure they have some great offers as well. 😉

That’s it. Have fun building your project for free!

If you want to know about my journey of building serverless SaaS products on AWS, consider following my Twitter 🙂