Hi all, I have the following issue: 1. Dev A works on a serverless stack project and pushes all the code to git. It works when they run

npm run start

for debugging. 2. Dev B then clones the repo, and runs

npm run start

, but this throws an error :

table xyz already exists

What would be the best way around this?

Use different, developer-specific stages

^ this is the way 😄

@Ross Coundon @Aram, thanks - I will take a look (hoping I can use the data that Dev A wrote in the other stage)

@Fazi if you need to share resources like a table, you should deploy those shared resources in its own stack for a stage called "shared" or something. Then for non-shared stages you can import the table

Thanks @Gabriel Araújo - will take a look. @thdxr, thanks - this came up because several developers were working on making changes to lambda functions the integration environment. These lambda functions in turn sourced data from large Dynamo tables we had populated in our integration environment (it would take a fair bit of time to repopulate them again and again for each developer).

Got it I'll share some example code with you

Thanks a lot @thdxr

this is pseudo code so won't exactly work

class TableStack extends sst.Stack {
  public readonly table: sst.
  constructor(scope) {
    super(scope, "table")
    if (scope.stage === "shared") {
      this.table = new Table(...)
      return
    }
    this.table = new sst.Table(this, "table", { dynamodbTable: dynamodb.Table.fromTableName(this, "Imported", "tablename") } )  
}

Thanks a lot @thdxr! I will see if I can make it work

Yeah this is a nice way of separating shared resources within the same app @thdxr!

Do you have any experience on how to share resources with the multiple dev aws account setup?

So that would be a different account per stage?

yes, different per stage and different account per each developer. Like the last one described here: https://docs.serverless-stack.com/working-with-your-team

It's technically possible with AWS RAM but it's a huge pain

It seems like the key to this strategy is not only deploying to a "shared" stage, but specifying the stack when deploying. For example, assume my stack(s) create multiple resources (API Gateway, Lambdas, DynamoDB Table, Cognito User Pool, etc). Using the above example, assume I want to share only the DDB table, but every other resource should not be shared. In this example, deploying to a shared environment (e.g.

sst deploy --stage shared

) would deploy all the resources to a stage named

shared

, which is not what I want I can think of at least two ways to address this: 1. Only deploy the single stack to the shared environment (e.g.

sst deploy <shared_stack_name> --stage shared

) 2. Apply the above conditional deploy logic to each resource created by your stack (probably a bad idea). Sometimes I want to combine long-lived resources (e.g. dev/stage/prod) with ephemeral resources in my development environment. This is desirable when there is a non serverless piece of my architecture (e.g RDS, OpenSearch, etc).