Hot-reloading webpack assets in combination with SAM local

[tomasaschan]

When writing a web app on top of a serverless backend, a really powerful setup for local development is almost possible using Webpack Dev Server and SAM Local.

Here's where I am now:

• SAM Local can serve my backend endpoints, with hot replacement of functions, on e.g. localhost:3000
• Webpack can serve everything, and support hot module replacement, on e.g. localhost:3001
• The web app on localhost:3001 cannot make requests to the backend, because they're on different ports and are thus blocked when no CORS headers are present.

A couple of ways to tie all this up and make it work would be

• Support CORS headers in SAM Local. I undersand it's being worked on on the SAM side of things, but I also appreciate that it's a complex problem. And I don't know if SAM Local starts supporting it OOTB when that feature lands, so there might be more work required here, too.

• Support falling back to forwarding requests to a different host. Today, the --static-dir flag allows serving static assets for anything there isn't a configured endpoint for - maybe there could be a --forwarding-fallback option (with a good name...)?

The second option is intended to allow me to run sam local start-api --forwarding-fallback localhost:3001 in one terminal, and webpack-dev-server in another, to serve SAM Local on 3000 and Webpack Dev Server on 3001. If I then go to localhost:3000, it forwards the request to 3001, and sends the response back, yielding a client that thinks it's being served from localhost:3000 and thus has no problem reaching the backend. This still allows for using Webpack's hot module reloading features for really rapid client-side development, while also having the backend available.

What do you think - is this feasible, and if so, desirable?

[sanathkr]

How would this scenario work on the cloud? Where would your webpack server live? We want to converge on an experience that is similar to your final cloud experience

[tomasaschan]

@sanathkr It wouldn't. The webpack-dev-server scenario is really only useful when you're working on a client-side application that uses a serverless backend for data retrieval (i.e. you may or may not be interested in actually changing the serverless functions etc). It's useful to be able to have a rapid dev cycle on the client-side app, as allowed by webpack-dev-server and HMR, while still targeting backend functions on SAM Local (so you don't have to setup a stack on AWS for each developer's local development needs).

If you'd want to run a more production-like setup, you'd use --static-dir as you do today.

[sanathkr]

Sounds good. So it is to give a tighter dev cycle for client-side apps. I have marked it as a feature request to gather feedback. And, if you haven't already noticed, I started some discussion in similar spirit. If you are interested in helping us build this, let me know. Happy to guide you through!

[jfuss]

Closing as there hasn't been any progress. If there are things we can still to tighten the dev loop, please open a new issue for that request.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.