Good morning everyone, just trying to get some thoughts/ideas on how you guys ‘feed’ (or seed) your database for dev (local) purposes? There are some scenarios where you build something that you need to spin up with some pre-seeded data so you can go straight and work on your features around that data, is there any well adopted approach for do this? It's also helpful when you introduce new developers in your team so they can just spin up the app and they can replicate some behavior (with pre-seeded data) since the first minute they just spin up the app on their side

I've done it using the Script construct.

const seedDynamoDbFunction = new sst.Function(this, 'dynamodbSeedFunction', {
        handler: 'src/main/scripts/index.seedDynamoDb',
        environment: commonEnvironment,
        permissions: [omwPrimaryTable],
        enableLiveDev: false,
      });
      new sst.Script(this, 'seedDynamoDbScript', {
        onCreate: seedDynamoDbFunction,
      });

You can do whatever you like in that function to set up your data

For more complex cases.. I use a playbook page.. where we define "plays" for each scenario that the develop may want.. for example: • users ready to onboard • users with no friends • users with 1k friends • etc.. Make this available only for non-prod envs and the "play" button call a lambda that does the magic.. And scripts for basic after deploy data..

got it, I guess the @Ross Coundon’s script construct makes sense in my particular and very specific use-case, but you also have an interesting approach there @Gabriel Araújo, I can see value on doing that for a couple other scenarios I run here as always, TY all! awesome community

Hey @Gabriel Araújo, the playbook idea makes a lot of sense. In the new Console, you will be able to invoke a Lambda function. So you can have a

Function

that isn’t being used by the app. And you can run it on demand though the Console.

this would force a dynamo table to store “play data”

Can you elaborate on this a bit more?

each play (lambda) would return data.. and we could store that data in dynamo and get this data for the lifetime of the environment or until we reset playbook data.. e.g.: imagine a place that generates users for testings.. each user in a different context. You turn up you environment and open sst console to check the playbook section to generate or get an user... Imagine we run: admin user.. the lambda function would run, generate the user and return data login info. We could store this as a play result and make this available in the console.. next time you don't need to run the data is already there..

@Tonny (sstNerd) there's something called a custom resource that's made for just that and fully automated too. You can attach hooks like onCreate that run operations on your table the moment it's provisioned. https://dev.to/elthrasher/exploring-aws-cdk-loading-dynamodb-with-custom-resources-jlf

sst script works for that... but my point is for more complex use cases and better development experience... imagine a QA running your app and need to test the system in a give context for a given user.. open the sst console and run play x.. off you go.. you can now test it..

@Gabriel Araújo appreciate the details! I opened an issue to track the Playbook idea you described. https://github.com/serverless-stack/serverless-stack/issues/1177