Lazy evaluation

[janat08]

There should be lazy evaluation for every handler.

[janat08]

You could just export a handler wrapper using some npm package.

[janat08]

https://github.com/sindresorhus/import-lazy this would improve performance right?

[kwhitley]

Hey @janat08 - Could you give me a scenario in which this would be relevant/important?

At a glance, my thoughts are, if your handlers are loading huge modules or whatever where this sort of performance tweaks would be useful, there's nothing stopping you from creating your own memoized handlers if you needed, or lazily importing modules, etc. Definitely doesn't seem to me (without further info) like something that should be baked into itty...

Perhaps I'm missing something here?

[janat08]

I suspect this should be recommended, unlike other serverless services that try to minimize hot starts, or whatever they're called, therefore not reinitializing for every request to then be priced by ms. Start up times for 1mb react app are somewhat significant from what i remember although part of that is dom, and the other part is just bundle evaluation. In terms of workers everything gets evaluated so that only specific set of code gets used once. It's just a suggestion that I'm not looking to implement myself manually with the mentioned package.

[kwhitley]

I mean, with CF workers, for instance, it’s all run through webpack… and bundled w the script for one. Secondly, you’re not typically loading huge client-side libraries through a worker anyway… and then there’s the fact that itty is ~460 bytes. You’d expect be adding a bigger library to memoize a small one. I think I see where you’re aiming w this one, but don’t think it applies much here…

if one were super interested in created a memoized itty for some reason, they’re welcome to fork and publish :) it’s open source after all!

[janat08]

Reason for why package I mentioned exists is that it somehow makes the package that gets loaded entirely for lack of tree shaking not necessarily evaluated entirely. Lazy languages support infinite recursive functions which is mimicked with generators in JavaScript. Anyway I didn’t didn’t immediately find package for making handler function lazy such that if you were to call a handler a second time it would return complete pie number which would never happen in cf workers, so the execution of first call wouldn’t halt because worker is trying to compute pie for the second call. I wager lazy handlers could be implemented by calling them via generator if thats how that import function is written.