Ever customized Lambda runtime environment for Nod...
# help
ö
Ever customized Lambda runtime environment for Nodejs? What I have in my mind is to remove
aws-sdk
package, as I never use it. And it is like 10 MB, as far as the runtime initilization will be faster with smaller size.
r
If you don't mind automatic version upgrades, you don't have to bundle it, it's part of the image in which your lambda runs, like it or not. If you want to reduce the size you could move to the treeshakeable and TypeScript v3 SDK. I've started moving our stuff over to it, mainly because the interface is more consistent.
ö
Yeah, that’s what I do as well. I don’t use aws-sdk at all, I use v3. But aws-sdk is still part of the runtime envrionment, and I would like to remove it
r
You can't, but it doesn't affect you. It's just part of the image
j
If you are concerned about performance you should consider the limitations of node.js and just learn golang.
ö
Does it make much difference in the case of lambda? Because each lambda can only handle one request, meaning that you cannot really benefit from concurrency features of the language
Also after reading this Discord blog, I guess I would learn Rust instead of Go https://discord.com/blog/why-discord-is-switching-from-go-to-rust
Rust has potential, Golang has a bigger community though. Much easier to hire experienced Golang developers than something like Rust
There’s also more open source projects in Go
I will take a look at Rust in a couple of years. Right now it would be difficult to hire Rust talent
ö
Yes you’re right
Idk I have started with Node once
lol
r
It's always good to learn a few languages. Rust seems a pretty steep learning curve from what I've briefly seen. I used to write C++ and Java back in the day and it seemed closer to those languages than something like Go from my quick peak. Go has its pros and cons too, as do all languages. In my experience not a lot of people, particularly in a serverless web app environment, have a use case that exceeds node.js's capabilities.
j
Rust is overkill for lambdas. Having read the Discord explanation, it doesn’t apply to short lived nanoservices. They are talking about long-lived applications where garbage collection is the problem. I do see some benefit to using Go instead of Node.js for simple Lambda functions. That is in performance and the confidence of a statically typed language. TypeScript is essentially a bandaid for JS and should stay on the frontend.
r
TypeScript is essentially a bandaid for JS and should stay on the frontend.
Well, I don't really agree with you on this. Having written in various static typed languages like C, C++, Java, C# etc over the years, I find TypeScript offers a very powerful type system. Node.js works very well for many use cases as has been proven by the sheer volume of successful products and services that have been built on it over the last few years, including those my company has built. Paired with TypeScript it's very versatile, safe and powerful. Go, when I looked at it, was really awkward in some quite common situations, missing function overloading, generics, and error handling requires what feels like reams of repeated code. In my humble opinion, TypeScript offers far more elegant solutions to these problems (the situation on these things may have been improved in Go over the last couple of years - happy to be corrected!). Is it right for every use case? Of course not, but no language or framework is.
Yes, agreed,
any
is awful. Casting is possible in pretty much any typed language and any casting (or use of any in general) can easily be prohibited using strict settings