inject into stack instead living separately

[mvayngrib]

if this function were injected into serverless.yml during preprocessing, then it could benefit from other goodies that serverless.yml functions enjoy: logging, command line invocation, etc.

[mvayngrib]

this will also prevent the second packaging call, which is currently really slow: serverless/serverless#4355

[goncaloneves]

Hi @mvayngrib.

Thanks for your feedback. 👌

Are you saying hook warmup to one initial event, inject it to the service and make warmup available to most of the SLS commands? Or is there more to it?

[mvayngrib]

@goncaloneves idk if what i was suggesting is possible for serverless plugins. I was thinking inject it into the serverless.yml functions block during some initial parsing phase, so the rest of the packaging/deployment process treats it like a regular function. Then it doesn't need to suffer from a separate packaging/deployment pipeline.

[juanjoDiaz]

That's exactly how it works @mvayngrib.
It uses the package individually option to package it separately from the other lambdas if you are not packaging them individually.

What are you missing exactly?

[mvayngrib]

@juanjoDiaz serverless has a pretty slow excludeDevDependencies operation during package. So when you run sls deploy, excludeDevDependencies ends up running twice (once for the rest of the functions, and once for the individually packed warm-up function). It's a problem on the framework side, but in my own project I removed package individually for the speed boost as I don't find myself deploying functions one at a time too often.

[juanjoDiaz]

That's interesting.

Serverless uses globby to do the includes and excludes (which indeed seems to be slow based on sindresorhus/globby#43).

I'm not 100% how serverless does it, But I would expect to run globby per function to find what should be include. That would mean that the speed should depend on how complex your include/exclude are in each function. So the speed of packaging the warmup lambda should be the same for an enormous project and for a project with 2 lambdas.

Isn't that the case?

[mvayngrib]

@juanjoDiaz theoretically, yes :) but in practice, no. Even a function with zero deps will fall into the excludeDevDependencies time warp. See these issues:
serverless/serverless#4355
serverless/serverless#4345

[dougmoscrop]

I'm not sure this plugin even needs to in inject functions. Why can't it just add a cloudwatch event?

[goncaloneves]

@dougmoscrop it could in it's current form, would make it simpler. But the intention of this plugin is to be able to deal with #24 eventually and not be just a schedule.

For now I don't have time to dedicate to this, but is something that I am curious to build and see how it will play out.

Closing this issue, nothing to be done on warmup side here.

[OJFord]

We have tonnes of instances of warmup left behind after the Serverless-created stacks they were for have been deleted. I'd like it if warmup's resources (functions, cloudwatch events, whatever) were a part of the stack just to make it easy to ensure it's deleted along with it.

#51 added tags which helps, but annoying (especially retrospectively) to add separately from the provider.tags which aren't inherited.

[juanjoDiaz]

Hi @OJFord,

As mentioned in the older messages, the warmer lambda is part of the serverless-created stack.
I do plenty of test and whenever I do serverless destroy the warmers and all the resources related to them are removed with the rest of the stack.

Are you using some old version? Or might the issue be somewhere else?
Can you create a sample project for me to replicate the issue?