AWS's Lambda Layers allows custom runtimes, lambdas for any language

Show and Tell
1

I wasn’t at re:invent this past week but I did hear the announcement of an addition to AWS Lambda called AWS Lambda Layers.

A layer is a ZIP archive that contains libraries, a custom runtime, or other dependencies.

You can implement an AWS Lambda runtime in any programming language. A runtime is a program that runs a Lambda function’s handler method when the function is invoked.

In short, it sounds like it’s now possible to create Elm lambda functions in AWS as long as there’s a custom Elm runtime available. I think this would be great to have. I’m interested to hear what the Elm community thinks.

2

Sounds good.

It was already possible to write AWS Lambda functions - I don’t think Elm needs much ‘customization’ to its runtime. In 0.18 there was a package called something like elm-serverless? You could use it to write AWS Lambda functions, but it has not been upgraded to 0.19.

3

I’ve had a serverless elm app running in production for about two months. There’s one or two gotchas but it works well.

The issue isn’t getting elm to run, there’s no ecosystem or api design for serverside stuff.

My serverless app was a stop-gap measure. Most of the functionality implemented in the app is moving to the client side in the next iteration, but we didn’t have time to implement for launch, so we replaced our existing serverless node.js server with this temporary elm one.

On the other hand, I really love the idea of being able to write pure functions in Haskell, or use the excellent language constructs in elixir on serverless.

4

Here is the elm-serverless package for 0.18:

https://package.elm-lang.org/packages/ktonon/elm-serverless/latest/

I’m now curious as to why it hasn’t made it to 0.19, was there some reason it could not be upgraded? I don’t think this package included any kernel code, but it does have src-bridge which is some js that wraps the Elm runtime. Changes to the Elm runtime might well have broken that.

I think the idea was that you call AWS services over their HTTP APIs.

5

Since there’s currently “no ecosystem or api design for serverside stuff” to speak of, I think it might be quite equalising for elm to start her backend journey from constrained environment like aws lambda or even cloudflare workers [than starting in more general server environments]

I’m experimenting with elm on “server side” and I’m liking how elm can make “http routes” handling much better than standard url/middleware approaches; looking forward to more discoveries in this space.

The lack of parallel Task execution does mean an elm version of the canonical “google search” be slow, albeit concurrent.

6

Honestly, I used elm/url to parse the urls into Routes, and with some very slight tweaks, it worked really, really well.

1 Like
7

used elm/url to parse the urls

Yes, same here elm/url is really good! But instead of keeping routes light, I’m finding value in loading more upfront work there – decoding headers and jwt into useful “request context” of custom types – then we could immediately do useful things when we start handling

( GET, Ok ({ userAgent, acceptLanguage } as context), Routes.Homepage ) ->
    ...
( GET, UserFromJWT, Routes.Homepage ) ->
    ...

looking forward to more discoveries in this space

I’m also experimenting with exposing only Task for the Elm SPA (instead of thinking in terms of http and url). But this seamlessness “worked too well”: sharing type encoder/decoder is nice but client code can get conflated with with server code; need more work on developer ux

8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.