The problem with that approach is that Graphicmagick binaries seem to require building from source on the OS, (tried several instructions on static linking the binary and I even made a Amazon Linux 2 Docker image to build it from source before zipping). It will complain about missing libJpeg.so files even if uploaded. If you happen to have time to play with it and end up with different results, feel free to let me know.
Here is a few routes I tried to build-it-and-zip-it and failed:
Copy the binary from ubuntu /usr/bin
Build in Docker Image of AWS Linux 2 and upload zip it
Try to build it as part of the function(terrible idea) but it is read-only env anyway so it does not work either
Build graphicmagick as part of the build pipeline and copy it into functions directory, it doesn’t quite work either since Amazon Linux 2 seems to be a different environment.
And they were very close to 50mb, once I try to include more .so files in the bundle, it can get to ~70mb. It got into a complicated Imagemagick building problem on minimizing the number of modules you need for your app, which is way too complicated for a simple use case.
At the end, I realize that this is unnecessary for some basic image processing. I ended up doing another Golang experiment for simple use cases(total golang binary size is only around 10mb).
I can try imagemagick and see if it works out differently but still, it looks like the zip-it-and-ship-it a node.js function without AWS Lambda layers is not a good idea if you want to leverage large dependencies like Imagemagick or Node-canvas(100mb). With Lambda layers, this would be provided by AWS, so it’s definitely worth looking into from Netlify perspective since image processing + upload to S3 was actually one of the example payloads when AWS first launches AWS Lambda.