sst
diff --git a/‎.gitignore
Lines changed: 3 additions & 0 deletions b/‎.gitignore
Lines changed: 3 additions & 0 deletions
diff --git a/‎Gemfile.lock
Lines changed: 3 additions & 2 deletions b/‎Gemfile.lock
Lines changed: 3 additions & 2 deletions
diff --git a/‎README.md
Lines changed: 2 additions & 1 deletion b/‎README.md
Lines changed: 2 additions & 1 deletion
diff --git a/‎_chapters/add-a-billing-api.md renamed to ‎_archives/add-a-billing-api.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/add-a-billing-api.md renamed to ‎_archives/add-a-billing-api.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/add-a-create-note-api.md renamed to ‎_archives/add-a-create-note-api.md
Lines changed: 4 additions & 3 deletions b/‎_chapters/add-a-create-note-api.md renamed to ‎_archives/add-a-create-note-api.md
Lines changed: 4 additions & 3 deletions
diff --git a/‎_chapters/add-a-delete-note-api.md renamed to ‎_archives/add-a-delete-note-api.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/add-a-delete-note-api.md renamed to ‎_archives/add-a-delete-note-api.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/add-a-get-note-api.md renamed to ‎_archives/add-a-get-note-api.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/add-a-get-note-api.md renamed to ‎_archives/add-a-get-note-api.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/add-a-list-all-the-notes-api.md renamed to ‎_archives/add-a-list-all-the-notes-api.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/add-a-list-all-the-notes-api.md renamed to ‎_archives/add-a-list-all-the-notes-api.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/add-an-update-note-api.md renamed to ‎_archives/add-an-update-note-api.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/add-an-update-note-api.md renamed to ‎_archives/add-an-update-note-api.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/add-support-for-es6-and-typescript.md renamed to ‎_archives/add-support-for-es6-and-typescript.md
Lines changed: 5 additions & 4 deletions b/‎_chapters/add-support-for-es6-and-typescript.md renamed to ‎_archives/add-support-for-es6-and-typescript.md
Lines changed: 5 additions & 4 deletions
diff --git a/‎_chapters/allow-users-to-change-passwords.md renamed to ‎_archives/allow-users-to-change-passwords.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/allow-users-to-change-passwords.md renamed to ‎_archives/allow-users-to-change-passwords.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/allow-users-to-change-their-email.md renamed to ‎_archives/allow-users-to-change-their-email.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/allow-users-to-change-their-email.md renamed to ‎_archives/allow-users-to-change-their-email.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/api-gateway-and-lambda-logs.md renamed to ‎_archives/api-gateway-and-lambda-logs.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/api-gateway-and-lambda-logs.md renamed to ‎_archives/api-gateway-and-lambda-logs.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/backups-in-dynamodb.md renamed to ‎_archives/backups-in-dynamodb.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/backups-in-dynamodb.md renamed to ‎_archives/backups-in-dynamodb.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/best-practices-for-building-serverless-apps.md renamed to ‎_archives/best-practices-for-building-serverless-apps.md
Lines changed: 18 additions & 17 deletions b/‎_chapters/best-practices-for-building-serverless-apps.md renamed to ‎_archives/best-practices-for-building-serverless-apps.md
Lines changed: 18 additions & 17 deletions
diff --git a/‎_chapters/code-splitting-in-create-react-app.md renamed to ‎_archives/code-splitting-in-create-react-app.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/code-splitting-in-create-react-app.md renamed to ‎_archives/code-splitting-in-create-react-app.md
Lines changed: 1 addition & 0 deletions
diff --git a/‎_chapters/cognito-user-pool-vs-identity-pool.md renamed to ‎_archives/cognito-user-pool-vs-identity-pool.md
Lines changed: 1 addition & 0 deletions b/‎_chapters/cognito-user-pool-vs-identity-pool.md renamed to ‎_archives/cognito-user-pool-vs-identity-pool.md
Lines changed: 1 addition & 0 deletions
@@ -1,4 +1,6 @@
 Session.vim
+.sst/
+node_modules/
 _site
 .sw*
 .*.sw*
@@ -7,3 +9,4 @@ _site
 .jekyll-cache/
 .DS_Store
 vendor/
+.idea/
@@ -72,6 +72,7 @@ GEM
 
 PLATFORMS
   arm64-darwin-21
+  x86_64-darwin-22
 
 DEPENDENCIES
   jekyll (= 4.1.1)
@@ -81,7 +82,7 @@ DEPENDENCIES
   webrick (~> 1.7)
 
 RUBY VERSION
-   ruby 3.0.4p208
+   ruby 2.6.10p210
 
 BUNDLED WITH
-   2.3.20
+   2.4.5
@@ -1,9 +1,10 @@
-<p align="center">
+<p style="text-align: center;">
   <a href="https://sst.dev/">
     <img alt="SST" src="https://raw.githubusercontent.com/sst/identity/main/variants/sst-full.svg" width="300" />
   </a>
 </p>
 
+
 <p align="center">
   <a href="https://sst.dev/discord"><img alt="Discord" src="https://img.shields.io/discord/983865673656705025?style=flat-square&label=Discord" /></a>
   <a href="https://twitter.com/sst_dev"><img alt="Twitter" src="https://img.shields.io/badge/Twitter-26a7de?style=flat-square" /></a>
 
@@ -6,6 +6,7 @@ lang: en
 description: We are going to create a Lambda function for our serverless billing API. It will take the Stripe token that is passed in from our app and use the Stripe JS SDK to process the payment.
 ref: add-a-billing-api
 comments_id: add-a-billing-api/170
+redirect_from: /chapters/add-a-billing-api.html
 ---
 
 Now let's get started with creating our billing API. It is going to take a Stripe token and the number of notes the user wants to store.
 
@@ -6,6 +6,7 @@ lang: en
 ref: add-a-create-note-api
 description: To allow users to create notes in our note taking app, we are going to add a create note POST API. To do this we are going to add a new Lambda function to our Serverless Framework project. The Lambda function will save the note to our DynamoDB table and return the newly created note.
 comments_id: add-a-create-note-api/125
+redirect_from: /chapters/add-a-create-note-api.html
 ---
 
 Let's get started on our backend by first adding an API to create a note. This API will take the note object as the input and store it in the database with a new id. The note object will contain the `content` field (the content of the note) and an `attachment` field (the URL to the uploaded file).
@@ -67,7 +68,7 @@ There are some helpful comments in the code but we are doing a few simple things
 - The AWS JS SDK assumes the region based on the current region of the Lambda function. So if your DynamoDB table is in a different region, make sure to set it by calling `AWS.config.update({ region: "my-region" });` before initializing the DynamoDB client.
 - Parse the input from the `event.body`. This represents the HTTP request body.
 - It contains the contents of the note, as a string — `content`.
-- It also contains an `attachment`, if one exists. It's the filename of file that has been uploaded to [our S3 bucket]({% link _chapters/create-an-s3-bucket-for-file-uploads.md %}).
+- It also contains an `attachment`, if one exists. It's the filename of file that has been uploaded to [our S3 bucket]({% link _archives/create-an-s3-bucket-for-file-uploads.md %}).
 - We read the name of our DynamoDB table from the environment variable using `process.env.tableName`. We'll be setting this in our `serverless.yml` below. We do this so we won't have to hardcode it in every function.
 - The `userId` is the id for the author of the note. For now we are hardcoding it to `123`. Later we'll be setting this based on the authenticated user.
 - Make a call to DynamoDB to put a new object with a generated `noteId` and the current date as the `createdAt`.
@@ -129,7 +130,7 @@ functions:
           method: post
 ```
 
-Here we are adding our newly added create function to the configuration. We specify that it handles `post` requests at the `/notes` endpoint. This pattern of using a single Lambda function to respond to a single HTTP event is very much like the [Microservices architecture](https://en.wikipedia.org/wiki/Microservices). We discuss this and a few other patterns in the chapter on [organizing Serverless Framework projects]({% link _chapters/organizing-serverless-projects.md %}).
+Here we are adding our newly added create function to the configuration. We specify that it handles `post` requests at the `/notes` endpoint. This pattern of using a single Lambda function to respond to a single HTTP event is very much like the [Microservices architecture](https://en.wikipedia.org/wiki/Microservices). We discuss this and a few other patterns in the chapter on [organizing Serverless Framework projects]({% link _archives/organizing-serverless-projects.md %}).
 
 The `environment:` block allows us to define environment variables for our Lambda function. These are made available under the `process.env` Node.js variable. In our specific case, we are using `process.env.tableName` to access the name of our DynamoDB table.
 
@@ -167,7 +168,7 @@ If you have multiple profiles for your AWS SDK credentials, you will need to exp
 $ AWS_PROFILE=myProfile serverless invoke local --function create --path mocks/create-event.json
 ```
 
-Where `myProfile` is the name of the AWS profile you want to use. If you need more info on how to work with AWS profiles in Serverless, refer to our [Configure multiple AWS profiles]({% link _chapters/configure-multiple-aws-profiles.md %}) chapter.
+Where `myProfile` is the name of the AWS profile you want to use. If you need more info on how to work with AWS profiles in Serverless, refer to our [Configure multiple AWS profiles]({% link _archives/configure-multiple-aws-profiles.md %}) chapter.
 
 The response should look similar to this.
 
 
@@ -6,6 +6,7 @@ lang: en
 ref: add-a-delete-note-api
 description: To allow users to delete their notes in our note taking app, we are going to add a DELETE note API. To do this we will add a new Lambda function to our Serverless Framework project. The Lambda function will delete a user’s note in the DynamoDB table.
 comments_id: add-a-delete-note-api/153
+redirect_from: /chapters/add-a-delete-note-api.html
 ---
 
 Finally, we are going to create an API that allows a user to delete a given note.
 
@@ -6,6 +6,7 @@ lang: en
 ref: add-a-get-note-api
 description: To allow users to retrieve a note in our note taking app, we are going to add a GET note API. To do this we will add a new Lambda function to our Serverless Framework project. The Lambda function will retrieve the note from our DynamoDB table.
 comments_id: add-a-get-note-api/132
+redirect_from: /chapters/add-a-get-note-api.html
 ---
 
 Now that we created a note and saved it to our database. Let's add an API to retrieve a note given its id.
 
@@ -6,6 +6,7 @@ lang: en
 ref: add-a-list-all-the-notes-api
 description: To allow users to retrieve their notes in our note taking app, we are going to add a list note GET API. To do this we will add a new Lambda function to our Serverless Framework project. The Lambda function will retrieve all the user’s notes from the DynamoDB table.
 comments_id: add-a-list-all-the-notes-api/147
+redirect_from: /chapters/add-a-list-all-the-notes-api.html
 ---
 
 Now we are going to add an API that returns a list of all the notes a user has.
 
@@ -6,6 +6,7 @@ lang: en
 ref: add-an-update-note-api
 description: To allow users to update their notes in our note taking app, we are going to add an update note PUT API. To do this we will add a new Lambda function to our Serverless Framework project. The Lambda function will update a user’s note in the DynamoDB table.
 comments_id: add-an-update-note-api/144
+redirect_from: /chapters/add-an-update-note-api.html
 ---
 
 Now let's create an API that allows a user to update a note with a new note object given its id.
 
@@ -4,11 +4,12 @@ title: Add Support for ES6 and TypeScript
 date: 2016-12-29 12:00:00
 lang: en
 ref: add-support-for-es6-and-typescript
+description: AWS Lambda supports Node.js v10.x and v12.x. However, to use ES 6 features or TypeScript in our Serverless Framework project we need to use Babel, Webpack 5, and a ton of other packages. We can do this by using the serverless-bundle plugin to our project.
+comments_id: add-support-for-es6-es7-javascript/128
 redirect_from:
   - /chapters/add-support-for-es6-javascript.html
   - /chapters/add-support-for-es6-es7-javascript.html
-description: AWS Lambda supports Node.js v10.x and v12.x. However, to use ES 6 features or TypeScript in our Serverless Framework project we need to use Babel, Webpack 5, and a ton of other packages. We can do this by using the serverless-bundle plugin to our project.
-comments_id: add-support-for-es6-es7-javascript/128
+  - /chapters/add-support-for-es6-and-typescript.html
 ---
 
 AWS Lambda supports Node.js v10.x, v12.x, and v14.x. However, the supported syntax is a little different when compared to the more advanced ECMAScript flavor of JavaScript that our frontend React app supports. It makes sense to use similar ES features across both parts of the project – specifically, we'll be relying on ES imports/exports in our handler functions.
@@ -26,7 +27,7 @@ To help with this we created, [`serverless-bundle`](https://github.com/AnomalyIn
 - Supports transpiling unit tests with [babel-jest](https://github.com/facebook/jest/tree/master/packages/babel-jest)
 - Source map support for proper error messages
 
-It's automatically included in the starter project we used in the previous chapter — [`serverless-nodejs-starter`]({% link _chapters/serverless-nodejs-starter.md %}). For TypeScript, we have a starter for that as well — [`serverless-typescript-starter`](https://github.com/AnomalyInnovations/serverless-typescript-starter).
+It's automatically included in the starter project we used in the previous chapter — [`serverless-nodejs-starter`]({% link _archives/serverless-nodejs-starter.md %}). For TypeScript, we have a starter for that as well — [`serverless-typescript-starter`](https://github.com/AnomalyInnovations/serverless-typescript-starter).
 
 However, if you are looking to add ES6 and TypeScript support to your existing Serverless Framework projects, you can do this by installing [serverless-bundle](https://github.com/AnomalyInnovations/serverless-bundle):
 
@@ -89,7 +90,7 @@ You should see something like this in your terminal.
 
 In the above command we are asking Serverless Framework to (locally) invoke a Lambda function called `hello`. This in turn will run the `hello` method that we are exporting in our `handler.js`.
 
-Here we are directly invoking the Lambda function. Though once deployed, we'll be invoking this function through the `/hello` API endpoint (as we [talked about in the last chapter]({% link _chapters/setup-the-serverless-framework.md %})).
+Here we are directly invoking the Lambda function. Though once deployed, we'll be invoking this function through the `/hello` API endpoint (as we [talked about in the last chapter]({% link _archives/setup-the-serverless-framework.md %})).
 
 Now we are almost ready to deploy our Lambda function and API. But before we do that let's quickly look at one of the other things that's been set up for us in this starter project. 
 
 
@@ -5,6 +5,7 @@ description: Use the AWS Amplify Auth.changePassword method to support change pa
 date: 2018-04-15 00:00:00
 code: user-management
 comments_id: allow-users-to-change-passwords/507
+redirect_from: /chapters/allow-users-to-change-passwords.html
 ---
 
 For our [Serverless notes app](https://demo.sst.dev), we want to allow our users to change their password. Recall that we are using Cognito to manage our users and AWS Amplify in our React app. In this chapter we will look at how to do that.
 
@@ -5,6 +5,7 @@ description: Use the AWS Amplify Auth.updateUserAttributes method to support cha
 date: 2018-04-16 00:00:00
 code: user-management
 comments_id: allow-users-to-change-their-email/508
+redirect_from: /chapters/allow-users-to-change-their-email.html
 ---
 
 We want the users of our [Serverless notes app](https://demo.sst.dev) to be able to change their email. Recall that we are using Cognito to manage our users and AWS Amplify in our React app. In this chapter we will look at how to do that.
 
@@ -4,6 +4,7 @@ title: API Gateway and Lambda Logs
 description: To view logs for your serverless APIs on AWS, CloudWatch needs to be enabled for API Gateway and Lambda. CloudWatch logs are ordered by Log Groups and Log Stream. Lambda CloudWatch logs can also be viewed using the Serverless CLI with the “serverless logs” command.
 date: 2018-04-03 00:00:00
 comments_id: api-gateway-and-lambda-logs/31
+redirect_from: /chapters/api-gateway-and-lambda-logs.html
 ---
 
 Logging is an essential part of building backends and it is no different for a serverless API. It gives us visibility into how we are processing and responding to incoming requests.
 
@@ -4,6 +4,7 @@ title: Backups in DynamoDB
 date: 2018-04-06 12:00:00
 description: Amazon DynamoDB allows you to create On-demand backups and enable Point-in-time recovery with a single click. Backups are fully-managed, extremely fast, and do not impact performance. In this chapter we look at the two ways to backup and restore DynamoDB tables.
 comments_id: backups-in-dynamodb/705
+redirect_from: /chapters/backups-in-dynamodb.html
 ---
 
 An important (yet overlooked) aspect of having a database powering your web application are, backups! In this chapter we are going to take a look at how to configure backups for your DynamoDB tables.
 
@@ -4,6 +4,7 @@ title: Best Practices for Building Serverless Apps
 description: In this section of the guide we'll be covering the best practices for developing and maintaining large Serverless applications. It builds on what we've covered so far and it extends the demo notes app that we built in the first section. It's intended for teams as opposed to individual developers. It's meant to give you a foundation that scales as your app (and team) grows.
 date: 2019-10-03 00:00:00
 comments_id: best-practices-for-building-serverless-apps/1315
+redirect_from: /chapters/best-practices-for-building-serverless-apps.html
 ---
 
 In this section of the guide we'll be covering the best practices for developing and maintaining large Serverless applications. It builds on what we've covered so far and it extends the [demo notes app]({{ site.demo_url }}) that we built in the first section. It's intended for teams as opposed to individual developers. It's meant to give you a foundation that scales as your app (and team) grows.
@@ -41,23 +42,23 @@ Here is a rough rundown of the topics covered in this section of the guide.
 
 We are covering primarily the backend Serverless portion. The frontend flow works relatively the same way as what we covered in the first section. We also found that there is a distinct lack of best practices for building Serverless backends as opposed to React apps.
 
-- [Organizing large Serverless apps]({% link _chapters/organizing-serverless-projects.md %})
-  - [Sharing resources using cross-stack references]({% link _chapters/cross-stack-references-in-serverless.md %})
-  - [Sharing code between services]({% link _chapters/share-code-between-services.md %})
-  - [Sharing API endpoints across services]({% link _chapters/share-an-api-endpoint-between-services.md %})
-- [Configuring environments]({% link _chapters/environments-in-serverless-apps.md %})
-  - [Using separate AWS accounts to manage environments ]({% link _chapters/structure-environments-across-aws-accounts.md %})
-  - [Parameterizing resource names]({% link _chapters/parameterize-serverless-resources-names.md %})
-  - [Managing environment specific configs]({% link _chapters/manage-environment-related-config.md %})
-  - [Best practices for handling secrets]({% link _chapters/storing-secrets-in-serverless-apps.md %})
-  - [Sharing domains across environments]({% link _chapters/share-route-53-domains-across-aws-accounts.md %})
-- [Development lifecycle]({% link _chapters/working-on-serverless-apps.md %})
-  - [Working locally]({% link _chapters/invoke-api-gateway-endpoints-locally.md %})
-  - [Creating feature environments]({% link _chapters/creating-feature-environments.md %})
-  - [Creating pull request environments]({% link _chapters/creating-pull-request-environments.md %})
-  - [Promoting to production]({% link _chapters/promoting-to-production.md %})
-  - [Handling rollbacks]({% link _chapters/rollback-changes.md %})
-- [Using AWS X-Ray to trace Lambda functions]({% link _chapters/tracing-serverless-apps-with-x-ray.md %})
+- [Organizing large Serverless apps]({% link _archives/organizing-serverless-projects.md %})
+  - [Sharing resources using cross-stack references]({% link _archives/cross-stack-references-in-serverless.md %})
+  - [Sharing code between services]({% link _archives/share-code-between-services.md %})
+  - [Sharing API endpoints across services]({% link _archives/share-an-api-endpoint-between-services.md %})
+- [Configuring environments]({% link _archives/environments-in-serverless-apps.md %})
+  - [Using separate AWS accounts to manage environments ]({% link _archives/structure-environments-across-aws-accounts.md %})
+  - [Parameterizing resource names]({% link _archives/parameterize-serverless-resources-names.md %})
+  - [Managing environment specific configs]({% link _archives/manage-environment-related-config.md %})
+  - [Best practices for handling secrets]({% link _archives/storing-secrets-in-serverless-apps.md %})
+  - [Sharing domains across environments]({% link _archives/share-route-53-domains-across-aws-accounts.md %})
+- [Development lifecycle]({% link _archives/working-on-serverless-apps.md %})
+  - [Working locally]({% link _archives/invoke-api-gateway-endpoints-locally.md %})
+  - [Creating feature environments]({% link _archives/creating-feature-environments.md %})
+  - [Creating pull request environments]({% link _archives/creating-pull-request-environments.md %})
+  - [Promoting to production]({% link _archives/promoting-to-production.md %})
+  - [Handling rollbacks]({% link _archives/rollback-changes.md %})
+- [Using AWS X-Ray to trace Lambda functions]({% link _archives/tracing-serverless-apps-with-x-ray.md %})
 
 We think these concepts should be a good starting point for your projects and you should be able to adapt them to fit your use case!
 
 
@@ -4,6 +4,7 @@ title: Code Splitting in Create React App
 description: Code splitting in Create React App is an easy way to reduce the size of your React.js app bundle. To do this in an app using React Router v5, we can asynchronously load our routes using the dynamic import() method that Create React App supports.
 date: 2018-04-17 00:00:00
 comments_id: code-splitting-in-create-react-app/98
+redirect_from: /chapters/code-splitting-in-create-react-app.html
 ---
 
 Code Splitting is not a necessary step for building React apps. But feel free to follow along if you are curious about what Code Splitting is and how it can help larger React apps.
 
@@ -6,6 +6,7 @@ lang: en
 ref: cognito-user-pool-vs-identity-pool
 description: Amazon Cognito User Pool is a service that helps manage your users and the sign-up and sign-in functionality for your mobile or web app. Cognito Identity Pool or Cognito Federated Identities is a service that uses identity providers (like Google, Facebook, or Cognito User Pool) to secure access to other AWS resources.
 comments_id: cognito-user-pool-vs-identity-pool/146
+redirect_from: /chapters/cognito-user-pool-vs-identity-pool.html
 ---
 
 We often get questions about the differences between the Cognito User Pool and the Identity Pool, so it is worth covering in detail. The two can seem a bit similar in function and it is not entirely clear what they are for. Let's first start with the official definitions.