Fork me on GitHub
#aws-lambda
<
2021-01-29
>
socksy14:01:07

cold startup time is probably not negligible, but perhaps that depends on the TTL on cloudfront... It's clearly a trade-off

Jakub Holý20:02:12

also cold-startup is not everything. Babashka itself is about 70MB (perhaps 20-30 when zipped) so the time to transfer it likely also plays a role.

socksy14:01:23

I understand babashka is probably the least amount of cold start time, but I'm not sure I'd want to bet a production system on it just yet — esp. when i'm not sure how extendible a script based on it is

socksy14:01:19

main reason for wanting it to be clj/s is due to having first class support for edn and uuids (backend and frontend are clj and cljs respectively)

socksy14:01:56

currently investigating https://github.com/vendia/serverless-express as an approach

borkdude14:01:27

@socksy I understand the trade-offs. babashka has full EDN and transit support including uuids. But the migration path from babashka to when you outgrow it, while preserving equally fast startup time, is port it to the JVM (should be almost no changes but adding a deps.edn file) and then compile it using GraalVM native-image (which babashka itself uses to compile to native)

socksy14:01:32

interesting, good point. Personally I'd still shy away from it somewhat because we haven't got any graal in production, and I'd personally be worried about the licensing conditions... (also it doesn't compile on nixos for a long time which means I can't easily develop it locally, but I suppose that could be solved with docker)

socksy14:01:41

EDN & transit support were some of the big pro points in babashka's favour

borkdude14:01:22

graalvm CE is free to use for any goal, including commercial

borkdude14:01:55

for local development you wouldn't need it, you can just use any JVM. to test the native build you could use a CI environment

Eamonn Sullivan14:01:05

The last time I tried to use graalvm to compile a programme (granted, quite a while ago) there were lots and lots of usages where it couldn't handle it. One particular one I remember is that it couldn't handle SSL cert authentication in REST calls. I could use a modified version of clj-http, but that was one of the features ripped out for graalvm support. Is that issue become less or are there still a lot of hoops (reflection, etc.) that you have to jump through? I would love to just use clj and compile to binaries, because that's what I use it for at work most of the time: dev-op style utils.

borkdude14:01:24

@UR71VR71S clj-http now works with GraalVM, it's quite easy to fix that problem. babashka comes with httpkit client and server included now which also use SSL

Eamonn Sullivan14:01:43

SSL was OK, it was specifically cert authentication. If they have fixed that, that's really good. I'll take another look!

Eamonn Sullivan14:01:28

{:client-auth :want} , specifically.

borkdude15:01:38

@UR71VR71S I'm not sure what this is about, but there have been lots of improvements in GraalVM since I started using it

Eamonn Sullivan15:01:26

Thanks. I'll give it another go. What I was referring to in that cryptic map (☝️ ) is the specific option that you have to give to clj-http so that it does client-cert authentication.

borkdude15:01:11

I don't find clj-http personally the best with GraalVM since it still has some runtime require stuff which makes GraalVM hold on to stuff

borkdude15:01:18

which bloats the native-image a bit

borkdude15:01:21

but it works