dherault / dherault/serverless-offline
Provide a way to invalidate spawned worker threads
- Dominant language
- JavaScript
- Stars
- 5.3k
- Forks
- 811
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 3
Description
## Feature Request
When you make code changes while developing handlers, it's pretty important that the server reliably uses the changed code when a request comes in. After v9, we are supposed to use `--reloadHandler` for this, so that serverless-offline will spawn new worker thread for each request that comes in, instead of reusing the existing ones. That works great.
However, the issue with `--reloadHandler` is that it'll reload all of the code for every request, as opposed to reloading once after each code change, making the server very slow when your client does lots of requests.
Would it be possible for serverless-offline to provide some kind of hook/API to invalidate or kill the worker threads that serverless-offline has spawned and force it to reload them when the next request comes in? So instead of thowing away the worker threads and reloading after every request, it'd instead keep the old ones around, essentially working like it does today if you omit `--reloadHandler`. But then there would be separate way to explicitly force it to throw existing workers away.
That way serverless-offline wouldn't even have to worry about file change monitoring etc, that concern could be moved to some plugin or other kind of wrapper. We could use the cached workers for all requests until the invalidation happens (which in practice would be after a code change), and after that everything would reload as expected.
Of course you can already get the same effect by using `nodemon` etc to restart the entire process, but that can be very, _very_ slow, so it's not really a better option that just using the `--reloadHandler`.
Contributor guide
Research direction
Start by tracing the --reloadHandler worker lifecycle and how spawned workers are reused between requests. Define the invalidation hook or API, when workers should be discarded, and how the next request recreates them; done means workers persist normally but can be explicitly invalidated without restarting the process.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100