Roadmap for this package?

[viyatgandhi]

Hi Team,

Is this package still actively maintained by Azure Team? Last commit was few months back. With increase in Azure Node.js serverless usage, it would be great if we can upgrade this package. Thanks.

[mhoeger]

Funcpack was made to address cold start issues for projects that have many files and dependencies. Right now, we're investing in Run-From-Zip, to address this problem. We're still not sure if we're going to continue maintaining funcpack (updating and responding to large issues) or if we will no longer maintain it as we move towards Run-From-Zip being the default experience (you can try it now too using the link above).

We'd also love to hear arguments to keep funcpack for user experience reasons too :)

[viyatgandhi]

@mhoeger Thanks for your response. If Run-From-Zip solves the problems, will happy to use it. I will try it on my dev/test env soon and post my feedback. Will keep this issue open so other's can know regarding the timeline of this package and maybe start using new option Run-From-Zip. Thanks.

[mhoeger]

Sounds great. Please do keep us posted!

[iyerusad]

Hi @mhoeger,

Any chance README.md can be updated with more detailed explanation of why favoring of Run-From-Package? The question I don't see addressed is: Why/How is a seemingly functional tree-shaking package being replaced by a new hosting option?

I ran a quick test of Run-From-Package deployment (containing full node_modules required for my project), and then additional quick test with another Run-From-Package deployment but with code that has been condensed by azure-functions-pack (and removing node_modules ofcourse). The resulting zip archives sizes were 3,054 KB vs 696KB, respectively - almost 5x size reduction! However, my limited testing after deploying each payload indicated the cold boot time stayed roughly the same (~25s for the code I ran in consumption plan). Both deployments excluded package.json.

It seems that while azure-functions-pack (and tree-shaking/dead-code removal in general) can offer improvements to deployment payload size, the original intent of azure-functions-pack was to reduce cold boot time in Azure Functions (in the form of tree-shaking and removing need to pull external dependencies) - and those benefits are now rendered immaterial by Run-From-Package (presumably through the loading of the package into memory on cold boot, where the differences between condensed/uncondensed code is too small to matter?).

[mhoeger]

Hey @iyerusad, you nailed it :) Both Run-From-Package and azure-functions-pack reduce cold start by targeting the same area: reducing the amount of time taken to read individual files in a deployed app from storage (this is an expensive operation). azure-functions-pack reduces file reading by condensing everything to one file. Run-From-Package reduces this by keeping files as one payload (and then using a virtual file system). Run-From-Package works for all languages and includes other benefits (including atomicity, predictability, faster delpoyment... read more here).

But to address your original ask - good idea, I'll definitely update the README!

[iyerusad]

Awesome! Really helps condense rational when people come looking at options to address cold boot. I will be moving our Azure function deployments to run from package for the other benefits.

[CastleArg]

Hi Team, I still can't help but feel we still need this project! I'm getting really slow cold start times even with run for package, and it seems silly not to perform the basic goodness of webpack by minifying and tree shaking. I feel both strategies should be used together.

[chearmstrong]

Sorry for commenting on an old issue, but I'm starting to explore Azure functions and trying to better understand some things around best practice and optimisations.

I've been pointed to use "Run from package" but I'm not sure I 100% get it just yet.

I usually work with AWS Lambda and I have experience with Webpack. I'm not clear if I should/could also use Webpack with "Run with package". I would normally output my Node.js code to a single .js file using Webpack (with minification and tree-shaking, etc).

Thanks in advance - looking to understand this more but it feels like I'm missing something.

[mhoeger]

Hi @chearmstrong ! Thanks for the ping - we generally point to "run from package" because tests showed that webpacking code didn't have a significant impact on cold start. That being said, we haven't run those tests in years now and it would be good to retest.

azure-functions-pack is essentially just webpacking, but it takes care of changing entry points in function.json files. Unlike lambda, a single function app (deployment instance) can contain multiple register to be triggered by multiple event sources. In general, we have a 1:1 mapping of event source registration (via function.json and entry point code (default is the index.js file next to function.json). When the code location changes to be encapsulated in one file, we need to add a property to function.json to point to where the handler code lives. This is really similar to the approach we take to support TypeScript: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node?tabs=v2#typescript

Currently, we're exploring an approach to function declarations that is code-based and not config-based (function.json). This would solve the webpack question by making azure-functions-pack irrelevant. If this can be implemented as expected, the timeline for something like this in preview is early next year.

We're avoiding maintaining this repo because it hasn't made the cut in terms of our priorities, and if you can help show that we should be looking into this with more urgency that would be greatly appreciated! I've filed this issue here to kinda track that exploration, although I do want to give the caveat that this issue may not see some love for a little while: https://github.com/Azure/azure-functions-nodejs-worker/issues/340

Let me know if that answered your question or if you have other input!

[chearmstrong]

@mhoeger Thanks for the reply. I think that makes sense for the most part - much appreciated. It certainly would be good to see if webpacking/bundling does make a difference to cold starts or performance in general.

For my own curiosity - is there any documentation that shows how "run from package" actually works, vs. not using that (or using only azure-functions-pack). What does the lifecycle of an event look like when I have "run from package" enabled?

Thanks in advance, and sorry for so many questions - just trying to fully understand how it works. 🛠

[mhoeger]

No problem! Thanks for the good questions - this post should give good details on "run from package": https://github.com/Azure/app-service-announcements/issues/84 !