-
- Private work.
- Watched 6 more aws re:invent breakout sessions on serverless and event-driven architectures.
- Pubsub is usually push. SQS and eventbridge can both support this.
- Integrating two services directly is direct. Integrating a single service as a publisher or subscriber is even easier, and you can scale to way more than n=2.
- The decoupling for EDA is worth a lot.
- Also consider first principles. Every application is event-driven at its core. Time doesn’t mean anything. We have cause and effect. Action and reaction. The software should match the physics of the system.
- EDA avoids throttle, gracefully handles sender/receiver downtime, allows consumption at subscriber’s chosen rate, so many good benefits. Many-many becomes trivial. Eric Johnson: https://www.linkedin.com/in/singledigit/.
- I like this guy’s presentation style: https://www.youtube.com/watch?v=KXR17uwLEC8.
- Serverlessland has a lot of cool patterns. Specify your serverless framework (sam, cdk, serverless, etc) and your language (python, js, etc) and aws services you want to connect (lambda, rds, etc). It will give you a functional template to copypaste. Example: https://serverlessland.com/patterns?framework=CDK&language=Python.
- Step functions, standard vs express. Use the former for longer running tasks, or fewer state transitions. Express is usually better/cheaper for all others.
- Harvested and replanted top 2 gardens.
- psql.
- You can obviously group by multiple cols. Does order matter?
coalesce(value, default) to convert nulls to something else (like 0), rather than using a full case statement. It will return the first non-null value, so you can use with iterables too.- Can also use
ifnull(value, default) for non-iterables in other SQLs.
- JP Morgan Chase alone processes >5k transactions per second. BTC is 7. Eth1 was a few times that. Eth2 can be closer to cc. Solana 65k.
- Supercontest.
- Lambda Web Adapter.
- Run webapps on lambda. https://github.com/awslabs/aws-lambda-web-adapter
- You have to package your app as a docker image. Lambda can run docker images instead of zip files.
- LWA is basically a shim that sits in the docker image between the lambda api and your http api. It will receive the event, handle it as necessary, and forward to your rest api. Then it will take the http resp and convert it to json for lambda return.
- No code changes. Multi-language/platform/framework. You can also continue developing/debugging/packaging/linting/testing in your familiar tools, rather than shifting all those SDLC workflows to new serverless processes.
- What about performance? You’re starting an entire webapp container and launching a webserver on every lambda function, yes. It’s a bit more overhead than starting a basic image with only that endpoint’s code, and no web interface.
- You also lose some granularity. Seems like you only have 1 lambda (basically the domain), and it manages all the routing natively in your app’s web framework. Unless a true serverless stack, where api gateway manages all endpoints and their corresponding lambda functions. This gives you granular logs/metrics/etc, native in the cloud – rather than requiring you to build it alongside your web framework.
