An Advanced TODO Application

Basically the same as course 1, but with a more advanced stack. We switch to AWS

• Why move to DynamoDB from Fauna/ WTF is DynamoDB
• Opening an AWS account
• Creating a DynamoDB table with Terraform and GH Actions (or not)
• Modeling our data for Dynamo ("single table design", pk/sk) (maybe with the NoSQL workbench thing?)
• The node.js documentclient. Fetching, Inserting, updating.
• Switching GraphQL API from Fauna to Dynamo (and solving IAM on netlify)
• Why we need to run on AWS Lambda (detachment of lifecycle, websockets, apigateway control, dynamo streams, IAM integration)
• WTF is the Serverless Framework vs serverless
• Copy graphql function to new dir, create serverless.yml, setting up CI/CD
• WTF is Auth anyway? (we no longer have netlify identity fanciness for JWT -> user)
• Exploring Netlify Identity tokens
• Writing a lambda authorizer function for netlify
• Cold Starts exist
• Enabling DynamoDB change data capture, tracking todos completed per day, deploying stream functions with serverless framework

Why Move to DynamoDB

aka: FaunaDB vs DynamoDB

FaunaDB supports serverless access patterns well, but it lacks some critical features as we build out a more feature-full application. DynamoDB streams, pricing comparison, FQL vs "NoSQL" data modeling, TTL,

• fauna has a GraphQL interface layered on top of it's query language FQL, but because it's layered on top of FQL you have to understand both FQL and how GraphQL SDL translates into FQL to work with it

Switching to DynamoDB

• Modeling our data (just TODOs)
• Getting items based on pk/sk
• Creating TODOS with the document client
• updating the state of TODOs
• Use dynamodb streams to update some analytics (todos completed per day)

Netlify Identity vs Auth0

When it comes to authentication and authorization, there are a few parts we need to care about. The user needs to

• be able to log in or sign up to our site
• We need to validate a token for a logged-in user in our functions
• get the user metadata (such as user id, role, etc) for further authorization
• apply that user metadata when making database requests for authorization, etc purposes

We can additionally require

• adding metadata to a user at signup
• adding metadata to a user in a job or after an action (such as Stripe subscription status)

Netlify has an integrated approach that enables user authentication as well as giving access

Authorizers and checking the Netlify JWKS

https://gotruejs-playground.netlify.com/

curl -H "Authorization: Bearer <your_access_token_here>" https://serverless-todo-netlify-fauna-egghead.netlify.com/.netlify/identity/user

Netlify Functions vs AWS Lambda

Netlify functions are built on top of AWS lambda, this means that porting a function from Netlify Functions to Lambda doesn't require code changes. It does require deployment changes though.

Introducing the Serverless Framework

How do we deploy functions to platforms like Netlify, AWS, Google Cloud, etc? Netlify, as we've seen, allows us to ship straight from our git repo to their platform. This gives us some nice properties like being able to roll back everything as a unit. As we start to ship more and more functions, it can be useful to detach their lifecycles from that of the core UI application (especially as we start to build out more clients like native apps, etc).