WebFlow is an outstanding website design, development, and hosting platform. The WebFlow API provides webhooks for a variety of important events, and it signs its webhook requests to allow users to validate webhook requests, and therefore confirm that requests actually come from WebFlow.
The below code sample shows how to verify WebFlow webhook requests in AWSLambda functions using Python invoked via a Function URL, although the code will show the principles for validating requests in any language or platform.
Modern serverless applications on AWS are complex with a lot of moving parts. Mapping a developer workflow onto those applications can be difficult. This article discusses the developer workflow I have developed for complex serverless applications at aleph0, with example CloudFormation template and GitHub Action snippetes to illustrate the concepts.
AWSLambda is Amazon’s FaaS product. Pound for pound, it’s one of the best serverless computing products on the market. Easy to use, inexpensive to run (among FaaS offerings), and with compelling features like Layers, Extensions, and SnapStart, Lambda is a rock-solid choice for building serverless architectures.
However, its managed nature cuts both ways. The same FaaS features that make it so easy to use for vanilla workloads — just upload your program and go — also make it hard to use for anything that requires even a little customization, like ML models. I’ve done some significant work building out complex lambda functions for Java lately, and while deploying these complex workloads on AWS Lambda using Java is complex, the reward — a perfectly elastic, pay-for-uptime microservice architecture — is well worth the effort. But it turns out there’s a lot of the “Lambda iceberg” below the water to understand before you can expect to get these complex serverless applications working with high performance and reliability.
In this blog series, I will unpack what I learned in my journey to deploy an OpenCV-backed ML model onto AWS Lambda with minimal cold start, and show how the process can be used to deploy ML models on other backends, like TensorFlow Lite, onto Lambda as well.
As part of optimizing the HumanGraphics product, I am investigating different cloud architectures and their tradeoffs. Documenting my current “default stack” for a new webapp with compute (like an API) seems like a good starting point. Here it is:
Experienced cloud engineers and architects should should look at this diagram and agree that it’s at least a sane approach to building webapps, although certainly there are others. However, a less experienced cloud user might not understand why this architecture is sane. It turns out that there’s a lot to unpack in even this simple architecture — feature differences, business pressures, tradeoffs, and more. Let’s get into it.
I’ve added a new custom base image for Java 21 on Lambda to complement the community base images already available for Java 17, Java 18, Java 19, and Java 20. You can find the images on the ECR Public Gallery and DockerHub and the source code on GitHub. Java 21 is an LTS release with some of the most exciting new features Java has seen in a long time, so everyone should be looking to upgrade ASAP!
There are a couple of known issues, particularly around CDS (Class Data Sharing), per the but they appear to be (mostly) cosmetic at first blush. It’ll be fun ironing that out.
I’m also looking forward to releasing a custom image for Java 21, too, as soon as an updated Amazon Corretto image drops.
The excellent PostgreSQL database supports the following syntax for the common upsert SQL pattern:
INSERT INTO table(id, column1, column2)
VALUES (@id, @value1, @value2)
ON CONFLICT (id) DO UPDATE
SET
column1=EXCLUDED.value1,
column2=EXCLUDED.value2
RETURNING *
With this syntax, you can insert a new row with the given values, or update the existing row to the given values, using the row’s primary key (or other indexed key). Very handy!
But did the resulting upserted row insert or update?
The writing system that people use can actually tell you a lot about the person: where they are, what language(s) they speak, and so on. The two main standards for writing systems are ISO 15924 and Unicode. They are closely related to each other, but not every ISO 15924 entry has a corresponding Unicode script, e.g., the Afaka writing system (Afak).
There and Back Again
I just released a new dataset to help people map from one to the other and identify writing systems that are mostly historic in interest, and therefore not interesting in a modern context.
