Re-use of assets bucket - self-mutating application perhaps?

[esimonetti]

Hello!

I am using server-side-website and I was wandering if it could be possible to have a self-mutating application. What I mean by that is to have a data file in the assets directory, which the application changes.

In theory, changing the permissions of the lambda permissions for the bucket could allow it.

Has anyone tried?
If you did, do you have a sample config?
If you didn't but know the direction, could you help lead the way?
Is it a bad idea? And if yes why?

Thanks!

[mnapoli]

It is unfortunately a bad idea 😅

Note: the S3 bucket is public and entirely managed by Lift. Do not store or upload files to the bucket, they will be removed by Lift on the next deployment. Instead, create a separate bucket to store any extra file.

from https://github.com/getlift/lift/blob/master/docs/server-side-website.md

I would recommend to create a separate (public) bucket.

[esimonetti]

:D Thank you.

I would be totally fine with the file(s) being gone after each deployment as they are for a "few hours data cache" instead of reaching out to third parties API constantly. The data is too big for cookies, and too small/infrequently changes to add a full blown database.

Creating a new bucket for that (and one for dev, stage and prod) maintaining URLs etc. sounds excessive though. Especially as I believe there are N of S3 buckets limits for each AWS account.

If I wanted to attempt this bad idea path, I would have to:
1- figure out how to reference/refer to the bucket
2- allow lambda to write to that bucket when I need to refresh those file(s) (I believe now it would not have permission to do that)
3- implement the writing/refreshing part as I would for any other newly created bucket

Anything else that I am not seeing?
Are 1 and 2 not so easy to achieve programmatically and consistently?

Thanks again!

[mnapoli]

Yes that sounds like it!

For 1 and 2, you can look in the generated CloudFormation (in .serverless/) to copy the ID of the bucket that is created. Then you can reference it in serverless.yml.