Hi all - first time trying out SST (thought I've been using the guide for years) and I'm blown away! (Will effuse in the general channel later) Comment on the NextJS example and tutorial: Can I suggest that we include a removal policy for the DynamoDB table. I realise it introduces a couple of lines into the code and the need for a brief explanation. But, I feel that's better than leaving a new user with an orphaned Table in their account. Happy to raise a PR if that helps. Example:

import * as sst from "@serverless-stack/resources";
import { RemovalPolicy } from "@aws-cdk/core";

export default class MyStack extends sst.Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    // Counter table - DynamoDB
    const table = new sst.Table(this, "Counter", {
      fields: {
        counter: sst.TableFieldType.STRING
      },
      primaryIndex: { partitionKey: "counter" },
      dynamodbTable: { removalPolicy: RemovalPolicy.DESTROY }
    });

    // Next.js app
    const site = new sst.NextjsSite(this, "Site", {
      path: "frontend",
      environment: {
        // Pass the table details
        REGION: scope.region,
        TABLE_NAME: table.tableName
      }
    });

    // NextJS access perms
    site.attachPermissions([table]);

    // Display site URL
    this.addOutputs({
      URL: site.url
    });
  }
}

I agree that those things should be covered - at least mentioned that you can do that - otherwise newbies have no idea what's going on 😄

@Robin @Tomasz Sobczyk awesome suggestion!

Ooh! Missed that one https://docs.serverless-stack.com/constructs/App#setdefaultremovalpolicy Thanks @Frank

Yeah that’s the one ^^ 👍

I would suggest to set it up by default to destroy stuff and then mention that this won't fly for prod :)

Yeah this is a good idea. I think the example should have that setting but only for your local stages. So people don’t leave it on by mistake?

I mean... I'm hoping no one goes to prod without any thinking right after reading the guide.

@Jay can you set removal policies per stage?

To keep it sunstainable - I have various env files for different stages - put there control parameters - and then do some variable statements within my stacks, e.g.:

That’s a cool pattern @Tomasz Sobczyk. Thanks for sharing!

By default it’s best to not delete databases, you never know until you know

In prod fully agree - nothing that is stateful should be allowed to be deleted

I guess the solution is to just design the right partition key from the start so that we don’t ever run into a situation that requires replacing the table. I guess this just means having a suitable release cycle as opposed to instantly promoting every commit to prod.

@Robin

can you set removal policies per stage?

Yup, you set the removal policy if

this.stage !== "prod"

, where

this

is the

<http://sst.App|sst.App>

object if you are doing this inside

index