Lambda@Edge – Preview

So we're getting C# and a new Node.js runtime for Lambda. Jeff, surely you're reading this - when are we getting Python 3 support as an additional runtime?

I've been waiting for months for re:invent in the hope that it would be announced today, only to be disappointed. I'm not the only one in this situation: stuck on Python 2.7, hitting issues left and right because of an ancient runtime that we no longer would care about were it not for Lambda.

Just today I hit another issue in production which impacted our webhook system. Wouldn't you know it, `json.dumps()` produces illegal json in Python 2.7 when you give it an IntEnum:

    >>> from enum import IntEnum; from json import dumps, loads
    >>> class E(IntEnum):
    ...  A = 1
    >>> dumps(E.A)
    'E.A'
    >>> loads(dumps(E.A))
    Traceback (most recent call last):
    ...
    ValueError: No JSON object could be decoded

Please. Do something about this. It's wasting so much time :(

This is very, very cool. It allows you to deploy application logic extremely close to the user (in terms of latency), and Cloudfront has an order of magnitude more edge locations than the other AWS services like EC2 and S3.

In fact, if the promised ability to read/write the request/response bodies does appear, it might be possible to deploy your entire website or app as a single Lambda@Edge function. (Not every app would fit within the size, memory, and CPU constraints, of course.)

The main limitation would probably be the fact that for each incoming HTTP request, your choices are limited to either making zero origin requests (i.e. the function generates the response directly) or one origin request. It's not clear how this could work if you wanted to make two origin requests and combine them to render a single response.

I'm totally going to sign up for the preview and play around with it! Especially if, like the regular node.js Lambda functions, you can include arbitrary Linux binaries with the function code. Compiled request-processing code would easily meet the 128MB/50ms criteria.

For what it's worth, here is the original thread:

https://news.ycombinator.com/item?id=13011120

This should definitely meet our needs in both cases: serving prerendered content when necessary, and also adding the security headers to the front end. And it's definitely a 10x better solution than having an extra EC2 instance with your private certs on it, just to run an nginx proxy with twenty lines of code.

While having minimal access to the request to do things like add headers is of course quite useful, the people I've known who most want code execution at the edge are either already using or looking at using ESI (Edge-Side Includes, as provided by Akamai and Varnish), in order to express things like "use the cached content for almost the entire page but add some per-user information to the response via a secondary virtual request (the content for which might also be cached at the edge!) for people who are logged on; they say that at some point they will allow access to and potentially modification of the body, but it isn't clear to me that this will be as potent as (even if it eventually becomes technically as powerful as) ESI.

> Because your JavaScript code will be part of the request/response path, it must be lean, mean, and self-contained. It cannot make calls to other web services and it cannot access other AWS resources. It must run within 128 MB of memory, and complete within 50 ms.

I'm having a hard time conceptualizing what kind of logic you would run on these edge functions?

You have access to headers, so also things like client cookies, so could you use that to potentially personalize/templatize the body (once they have body mutation abilities)?

Or is it really just about static content routing? Detect google bot user agent and send them to resource A versus B etc...

For anyone needing a minimal effort prerendering solution (server side render for most JS frameworks), i.e. the use case described by Jeff - I made https://www.prerender.cloud/

(you could use the prerendercloud npm middleware from the lambda edge)

Interesting... looks like something we might want to use to do URL rewriting for an S3-hosted SPA test environment, so that deep links resolve to the base of the SPA without having to use a more "dynamic" host like an EC2 instance running nginx. [edit] ah, nevermind, you have to be using CloudFront too.

I somewhat wonder if this will be used by malicious websites for cloaking. For those who are unaware of the term, cloaking is used by malicious websites/ads to render different content to search engines and bots than for real users to avoid detection by those automated agents.

This seems it might be a way to check if a user is logged-in or not and provide the appropriate page. I'm thinking if the user details are in a jwt or cookie, you could render the correct page on insecure routes.

you can use this to serve dynamic websites out of CDN, for example github pages, which we talk about as a static site but underneath it is a slow moving database (your git repo)