Static assets (HTML / JS) passthrough to S3

[mikeblum]

for documentation / HTML files to compliment an API

In a normal AWS lambda function we have the ability to passthrough a request as a proxy to an S3 bucket. Is there anyway to configure a Zappa/Requests endpoint to passthrough to an S3 bucket and return a static file?

use case:

Zappa-defined API endpoints at /api/

/ root path serves up the API documentation (generated via swagger) stored in a static S3 bucket-as-a-website

Is this out of scope for Zappa or a configuration challenge? I think with existing support for using S3 buckets for secrets, we can extend this to serve static files as well. This concept does violate the separation of the JSON API from the HTML /JS side but could be useful for serving documentation along with the API.

Thoughts?

[Miserlou]

This is a cool idea! I haven't thought about it, but it seems like it would be easy to define in a configuration file ex:

{
'dev': {
   's3_bucket': 'lmbda',
   'static': {
         's3_bucket': 'lmbda/static',
         'path': '/static'
    }
}

Is this what you're talking about?

If you could add that functionality, I'd gladly accept a PR.

[mikeblum]

Exactly - I think this could all be defined in the zappa configuration file. Would it be the responsibility of the dev to configure the S3 bucket appropriately or should zappa configure the bucket as a www-enabled bucket?

[Miserlou]

I think at least for the first pass it's the job of the deployer to configure the bucket to their needs, I don't think we can properly anticipate how they will want that configured.

[Miserlou]

This should actually use s3:// syntax as well, related #477

[gutomaia]

+1

[joer14]

Hi all,

I've just been thinking about how nice it would be to have something like this, so I'm happy to see I'm not alone here.

I'm considering working on a PR for this and had a few questions for the community/@Miserlou:

• In the zappa_settings.json config would we want to allow the user to specify their backend endpoint explicitly?
  e.g

{
'dev': {
   's3_bucket': 'lmbda',
   'static': {
         's3_bucket': 's3://lmbda/static',
         'path': '/static',
         'lambda_endpoint': '/api',
    }
}

• To merge this would you expect the existing rollback functionality to also work with the frontend?
  • Maybe we can add this later.
• In terms of functionality, on update, we'd sync the local frontend directory to the s3, removing any files that no longer exist on the local machine. Correct?
• And just to double check, at least for now we might as well keep things simple and not bring cloudfront into this, correct?

I don't know much about this stuff but am drawing inspiration from the serverless-apig-s3 plugin.

Thanks for zappa!

[joer14]

Also, I have a gist with a little code for creating buckets, and syncing a frontend dir to it. In my code I just make one bucket per stage dedicated to hosting the frontend. That way we can have an easy read everything policy. This might be useful for creating buckets for testing purposes, but sorry if its a distraction.