aws-lambda

socksy 2021-01-29T14:21:07.006800Z

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

Jakub Holý 2021-02-08T20:58:12.014500Z

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.

socksy 2021-01-29T14:22:23.007900Z

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

socksy 2021-01-29T14:23:19.008900Z

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)

socksy 2021-01-29T14:23:56.009100Z

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

borkdude 2021-01-29T14:35:27.010500Z

@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)

socksy 2021-01-29T14:38:32.010900Z

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)

socksy 2021-01-29T14:39:41.011100Z

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

borkdude 2021-01-29T14:42:22.011300Z

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

borkdude 2021-01-29T14:43:55.011500Z

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 Sullivan 2021-01-29T14:52:05.011700Z

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.

borkdude 2021-01-29T14:53:24.011900Z

@eamonn.sullivan 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 Sullivan 2021-01-29T14:56:43.012100Z

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

Eamonn Sullivan 2021-01-29T14:57:28.012300Z

{:client-auth :want} , specifically.

borkdude 2021-01-29T15:00:38.012500Z

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

Eamonn Sullivan 2021-01-29T15:07:26.012700Z

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.

borkdude 2021-01-29T15:08:11.012900Z

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

borkdude 2021-01-29T15:08:18.013100Z

which bloats the native-image a bit

borkdude 2021-01-29T15:08:21.013300Z

but it works