https://serverless-stack.com/ logo
#help
Title
# help
f

Fazi

11/23/2021, 11:28 AM
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?
r

Ross Coundon

11/23/2021, 11:28 AM
Use different, developer-specific stages
a

Aram

11/23/2021, 11:29 AM
^ this is the way 😄
f

Fazi

11/23/2021, 11:41 AM
@Ross Coundon @Aram, thanks - I will take a look (hoping I can use the data that Dev A wrote in the other stage)
Maybe this could bring some light
t

thdxr

11/23/2021, 1:36 PM
@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
However I recommend you don't share resources like this in development. If you remove the table name it'll generate a table for each developer and it won't conflict
f

Fazi

11/23/2021, 1:43 PM
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).
t

thdxr

11/23/2021, 1:50 PM
Got it I'll share some example code with you
f

Fazi

11/23/2021, 1:51 PM
Thanks a lot @thdxr
t

thdxr

11/23/2021, 2:06 PM
this is pseudo code so won't exactly work
Copy code
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") } )  
}
so you'd deploy
--stage shared
once
and then everyone else will import the table from there
f

Fazi

11/23/2021, 2:31 PM
Thanks a lot @thdxr! I will see if I can make it work
j

Jay

11/23/2021, 11:53 PM
Yeah this is a nice way of separating shared resources within the same app @thdxr!
s

Stan

11/24/2021, 3:36 PM
Do you have any experience on how to share resources with the multiple dev aws account setup?
j

Jay

11/24/2021, 3:38 PM
So that would be a different account per stage?
s

Stan

11/24/2021, 4:01 PM
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
t

thdxr

11/24/2021, 4:24 PM
It's technically possible with AWS RAM but it's a huge pain
s

Seth Geoghegan

03/07/2022, 3:46 PM
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).