3 ms·

Initialization code is mentioned... "In addition to that, consider whether you can move initialization code outside of the handler function." There's an examp

by tyingq 5y ago

Initialization code is mentioned... "In addition to that, consider whether you can move initialization code outside of the handler function." There's an example too, but this could use more emphasis. I see quite of a lot of code in the main body of lambdas that doesn't need to be run over and over, things that could be safely cached in a hashmap, etc.

lloydatkinson 5y ago
I think a lot of this comes from people forgetting what would be considered normal and good practice everywhere else but something about serverless functions causes people to treat them as a quick and dirty hack solution. Then the inevitable refactor when that becomes a problem.
- cmckn 5y ago
  Absolutely. Java Lambdas are often particularly bad in this respect; all the nice abstractions and class hierarchies seem to go out the window as soon as one “implements RequestHandler”. Everything is a singleton all of a sudden, environment variables being read statically, etc.. The worst Java codebases I’ve ever seen have been Lambdas :(
  - lloydatkinson 5y ago
    There was a worrying trend in the .NET space of this for Azure Functions but I think there was enough complaints - it's now possible to configure DI yourself and use the .NET config stuff for getting env variables.
arinlen 5y ago
> There's an example too, but this could use more emphasis. To be fair, handling lambda cold start is AWS lambda 101, and initialization is the starting point. I'd say that the only people not aware of this is those who are just taking their first steps. This requirement is even notorious in JDK lambdas, and leads to the need to use dependency injection frameworks to handle initialization and consequently favour compile-time dependency injection frameworks such as Dagger over runtime ones like Guice. > things that could be safely cached in a hashmap, etc. I'd add that caching data in /tmp to get it through lazy evaluation is also a quite basic technique. The contents of /tmp are preserved between some calls and checking if the data is still there is an effective technique to shave off some milliseconds.

by tyingq 5y ago

lloydatkinson 5y ago

I think a lot of this comes from people forgetting what would be considered normal and good practice everywhere else but something about serverless functions causes people to treat them as a quick and dirty hack solution. Then the inevitable refactor when that becomes a problem.

cmckn 5y ago
Absolutely. Java Lambdas are often particularly bad in this respect; all the nice abstractions and class hierarchies seem to go out the window as soon as one “implements RequestHandler”. Everything is a singleton all of a sudden, environment variables being read statically, etc.. The worst Java codebases I’ve ever seen have been Lambdas :(
- lloydatkinson 5y ago
  There was a worrying trend in the .NET space of this for Azure Functions but I think there was enough complaints - it's now possible to configure DI yourself and use the .NET config stuff for getting env variables.

arinlen 5y ago

> There's an example too, but this could use more emphasis. To be fair, handling lambda cold start is AWS lambda 101, and initialization is the starting point. I'd say that the only people not aware of this is those who are just taking their first steps. This requirement is even notorious in JDK lambdas, and leads to the need to use dependency injection frameworks to handle initialization and consequently favour compile-time dependency injection frameworks such as Dagger over runtime ones like Guice. > things that could be safely cached in a hashmap, etc. I'd add that caching data in /tmp to get it through lazy evaluation is also a quite basic technique. The contents of /tmp are preserved between some calls and checking if the data is still there is an effective technique to shave off some milliseconds.