In cases where startup time matters and you have a slow disk, bundling can drastically reduce the number of filesystem calls you have to make for large dependency graphs.
I have been playing around with building an Iroh Tunnel Sandstorm app that can connect two Sandstorm instances, and share some capabilities exposed from one Sandstorm instance to the other, as if the capabilities were local. Iroh has been very reliable throughout the process.
WebKit does allow outside contributions, though that example is perhaps not the most illustrative as it is from an Igalia employee. Igalia maintains substantial parts of WebKit and at this point has to be the #2 contributor other than Apple themselves.
I think you could in theory have a similar webkit-based stripped down headless crate that might have a good tradeoff of features, performance, and size.
I have a large rails app that was plagued with slow specs using factory_bot. Associations in factories are especially dangerous given how easy it is to build up big dependency chains. The single largest speedup was noting that nearly every test was in the context of a user and org, and creating a default_user and default_org fixture.
Would be interesting to see a benchmark with the rust binary with successively more “bloat” in the binary to separate out how much of the cold start is app start time vs app transfer time. It would also be useful to have the c++ lambda runtime there too; I expect it probably performs similarly to rust.
Tangent: when you have a lambda returning binary data, it’s pretty painful to have to encode it as base64 just so it can be serialized to json for the runtime. To add insult to injury, the base64 encoding is much more likely put you over the response size limits (6MB normally, 1MB via ALB). The c++ lambda runtime (and maybe rust?) lets you return non-JSON and do whatever you want, as it’s just POSTing to an endpoint within the lambda. So you can return a binary payload and just have your client handle the blob.
Sure, you can only use EC2, not use autoscaling or spot and instead just provision to your highest capacity needs, and not use any other AWS service that relies on dynamo as a dependency.
We still take some steps to mitigate control plane issues in what I consider a reasonable AWS setup (attempt to lock ASGs to prevent scale-down) but I place the control plane disappearing on the same level as the entire region going dark, and just run multi-region.
> we never had any issues, because we didn't depend on calling AWS APIs to continue operating. Things already running continue to run.
I think it was just luck of the draw that the failure happened in this way and not some other way. Even if APIs falling over but EC2 instances remaining up is a slightly more likely failure mode, it means you can't run autoscaling, can't depend on spot instances which in an outage you can lose and can't replace.
Even their transfer rates between AZs _in the same region_ are expensive, given they presumably own the fiber?
This aligns with their “you should be in multiple AZs” sales strategy, because self-hosted and third-party services can’t replicate data between AZs without expensive bandwidth costs, while their own managed services (ElastiCache, RDS, etc) can offer replication between zones for free.
This is a great project writeup, I did something _very_ similar for my son. (HT802, asterisk, twilio, calling relatives) With all of the NAT involved I could never get sjsip to work properly so I ended up having to use the old sip module, but looking at yours makes me want to revisit it.
Once you have asterisk set up and running, it becomes easy to also set up all sorts of other extensions like "check the weather" / "tell a joke" / "check the train statuses". I put up some code for it here: https://github.com/mnutt/rotary
Hotwired is a ruby gem that sits on top of Rails' existing Turbo approach: start with a regular server-rendered ERB page, layer on Turbo to allow for page updates without page refreshes (via XHR-fetched html fragments) and layer on Hotwire to sync state with websockets.
It's great, you can have it launch multiple processes on the same port using SO_REUSEPORT. Normally it'd be a bit of a pain to health check multiple processes running on the same port without some other machinery since it is possible to get into a state where all but one process is hung. Systemd watchdog will provide your service with a socket and expect updates on a regular interval or else it will consider your service dead. This socket is also very handy for service startup, to have your process just notify systemd it is ready rather than having to poll to see if your process is listening yet.
I vaguely remember that fly.io used to have a platform based on v8 isolates, I’m guessing the new platform is a bit of a pivot? I’m curious, was it just to support more platforms, or we’re there technical challenges with isolates?