Skip to content
This repository has been archived by the owner on Jul 19, 2024. It is now read-only.

Roadmap for this package? #84

Open
viyatgandhi opened this issue Jun 27, 2018 · 11 comments
Open

Roadmap for this package? #84

viyatgandhi opened this issue Jun 27, 2018 · 11 comments

Comments

@viyatgandhi
Copy link

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
Copy link
Contributor

mhoeger commented Jul 6, 2018

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
Copy link
Author

@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
Copy link
Contributor

mhoeger commented Jul 10, 2018

Sounds great. Please do keep us posted!

@iyerusad
Copy link

iyerusad commented Jan 16, 2019

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
Copy link
Contributor

mhoeger commented Jan 16, 2019

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
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor

mhoeger commented Oct 22, 2020

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: Azure/azure-functions-nodejs-worker#340

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

@chearmstrong
Copy link

@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
Copy link
Contributor

mhoeger commented Oct 28, 2020

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants