start-api automatic reload does not appear to be doing anything

[ryancole]

Hi folks,

I'm running the following command: sam local start-api

I'm running the above command inside of a directory that I created using the sam --init command. So, it's a directory with a template.yaml file in it, and an actual node.js lamba function project folder.

The console output from sam says that I do not need to restart the CLI for changes to take affect, but modifying my code does not appear to cause any sort of automatic reload.

Do I have to do anything specific to allow this to auto reload? I'm running Windows 10.

[jfuss]

You will need to build every time. The behavior is you do not need to restart the command and can update the folders with new code and have it reflected when hitting the api. With the introduction of sam build, you will need to build anytime your source or dependencies change. We are looking to make this easier with sam build --watch but that will not change the behavior of the sam local start-api command.

Closing as this is working as intended.

[felixhageloh]

when I run sam local start-api I get this output

You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template

Which suggests that automatic reloading is the intended behavior

[jfuss]

@felixhageloh Yes but that 'auto reloading' is not 'auto building'. The reloading in this is describing that you can update the contents of the CodeUri and see the changes without restarting the api. With the introduction of sam build, this notion changed slightly.

If you are using build, what this is saying is you can build the function without needing to restart. This is because build generates a template that is used behind the scenes that points to a build location. The confusion comes from, you as a customer only interact with the non-built function/template while the invoke can (if using build) interact with the generated built template. Maybe a rewording is in order here to make the expectation better but it is working as intended.

I create #921 to track the work for 'auto building' through sam build --watch.

Note: That output was from the pre-sam build stage.

[felixhageloh]

@jfuss thanks for the clarification. I spent some time reading the docs in the meantime and they also all clearly state that you need to run build again.

[eamarce]

Hey guys,

So, we created a small npm package based in nodemon (samwatch):

https://www.npmjs.com/package/samwatch

https://github.com/mxitgo/samwatch

The way it works is, it copies your js/json files as you save them from the source folder to the corresponding .aws-sam/build folder (as long as the names are the same for your lambda and the code uri in template.yaml).

That is useful to see your changes reflected on the fly if you are running sam local start-api, so you don't have to run sam build after every change.

On the other hand, if the corresponding file copy is not within the .aws-sam/build folder already, the package will trigger a sam build (unless you use n parameter).

The package has helped us get a hot reload feeling for our local lambda function development with sam.

I hope anyone can find it useful.

Thanks!

[Cunaguaro]

Hi @felixhageloh. maybe it is too late now but it can help to solve this issue.
I note that when I run "sam local invoke getHomePage", the path in the container volume load the .aws-sam/build folder. that indicates that hot-reloading never going to work because the container is mounting the build folder. that's is why you have to run "sam build" every time.

Mounting /media/valero61/SWA/ubuntu/workspace/cunaguaro product cataloge/.aws-sam/build/getHomePage

I deleted the build folder and run sam local invoke getHomePage, now container mounts the path to the root folder of the project. and now hot-reload is working again.

Mounting /media/valero61/SWA/ubuntu/workspace/cunaguaro product cataloge as /var/task:ro,delegated inside runtime container

[alex-nishikawa]

For local development I remove the .aws-sam build folder:

"start:local": "rm -r .aws-sam & tsc -w && sam local start-api"

I do watch for typescript compilation during hot-reloading.

To answer your question @ryancole,
sam local start-api looks for changes in the .aws-sam folder IF it exists, if not, then it looks for changes in the root directory of your project.

[jthomerson]

@jfuss I understand now that this is intended behavior, but could I suggest that you at least re-word the output of the local start-api command? It caught me, too

Eventual hot-reloading would be nice, but for now, please don't confuse brand new users with the message that implies hot-reloading.

[alex-nishikawa]

@jthomerson

The confusion is that sam local start-api will always pull from the .aws-sam folder IF it exists. If you remove that folder you really do have hot-reloading, i.e. any saved code changes will be reflected in the lambda WITHOUT having to call start-api again.

This was confusing though, and I can't remember if the documentation mentions this.

[jthomerson]

Fascinating. Thanks for the tip @alex-nishikawa! I still think that message in the SAM start-api output should be more clear about this, but at least now I learned 😁

[jjercx]

The confusion is that sam local start-api will always pull from the .aws-sam folder IF it exists. If you remove that folder you really do have hot-reloading, i.e. any saved code changes will be reflected in the lambda WITHOUT having to call start-api again.

This is true, what how does it work with the dependencies? I'm using ruby and even after running bundle install --path vendor/bundle the function doesn't seem to pick the gems

[jfuss]

The statements about where sam local start-api pulls from are incorrect. sam local start-api (like all other sam local commands) 'pull' from the location that is specified in the template. What you are actually referring to is that all of our commands look for a template located in .aws-sam/build. This was done so customers do not need to specify the built template directly.

Regardless, if you use sam build, you need to build after changes to have them reflected.

[stevenlafl]

--watch option appears to be removed from sam build making this even more cumbersome.

$ sam build --watch
Usage: sam build [OPTIONS] [FUNCTION_IDENTIFIER]
Try 'sam build --help' for help.

Error: no such option: --watch
$ sam --version
SAM CLI, version 1.15.0

[codeedog]

@jfuss

Forgive my ignorance and inexperience, but what is the value of sam build? Not what does it do, but why does it exist? I'd much prefer to have hot recompilation of my code during sam local start-api. In order to get any new code changes once I've already built a system, I have to kill the locally started api, build, then restart the local api. Why not just either (1) ignore the build directory from local start-api and integrate the build step into sam deploy? Or, automatically call sam build during the running start-api?

I can't think of any reason I'd want to have edited source code in my source tree with a running sam local start-api pointed at a prior version of the source build. That current running server would be what I'm testing against for the source code I'm actively editing and writing. Having two separate sources of truth feels terrible to me.

SO, what am I missing? There must be a good reason you've chosen to provide this separation of commands. You've written above "...but it is working as intended". I don't think anyone doubts it works as intended, what I'm (and others likely are) curious about is why you intend it to work this way?

What is the workflow that requires this behavior?

Thanks.