How could you possibly say this is doing it wrong? The only way you could batch requests in the way you describe is if you have 1 (or very small number) compute nodes. You would need all those requests to hit same node so you could try and batch. With serverless compute infrastructure (which is what this blog is demonstrating by using lambda) you can have 1 isolated process per request and therefore need a database that can actually handle this kind of load.
My guess is it's a matter of 'when' I have to deal with this. I've had the domain for a while, and this is something I've wanted to build for such a long time. Things fell into place when I was able to build a Swift SDK for Fastly's platform back in January this year. The stubborn engineer in me went ahead and used the domain anyway and launched what you see today.
This is a shameless plug, but I built Swift Cloud to help people build scalable backends in Swift: https://swift.cloud
Behind the scenes we compile Swift to WASM and deploy to Fastly's edge network, Compute@Edge. At my day job we are using this in production and serving thousands of requests per second on our Swift app. Overall it's a lot of fun to deploy Swift on server, but the developer UX still leaves a lot to be desired. Running and testing locally is still non-trivial.
Are there plans to release an HTTP API to make it easier to use with services like Fastly Compute@Edge and Cloudflare Workers? And if so would the API be global or region specific?
One thing I haven't seen with "serverless" databases is an easy way to dictate where data is stored. Mongo has a pretty clever mechanism in their global clusters to specify which regions/nodes/tags a document is stored in, and then you simply specify you want to connect to nearest cluster. Assuming your compute is only dealing with documents in the same region as the incoming request, this ends up working really well where you have a single, multi-region db, but in practice reads/writes go to the nearest node if the data model is planned accordingly.
A real world example of how I am using this in Mongo today: I run automated trading software that is deployed to many AWS regions, in order to trade as close to the respective exchange as possible. I tag each order, trade, position, etc. with the exchange region that it belongs to and I get really fast reads and writes because those documents are going to the closest node in same AWS region. The big win here is this is a single cluster, so my admin dashboard can still easily just connect to one cluster and query across all of these regions without changing any application code. Of course these admin/analytics queries are slower but absolutely worth the trade off.
Kenji is an absolute legend in the culinary world. I highly suggest you checkout his youtube channel, his wealth of knowledge (backed by his own experiments) is simply unmatched.
Wow thanks so much for pointing out the fixed length stream. I had been talking with a few people on your team and no one pointed me to that. That entirely solves our problem to getting things into production. Thanks a ton
Are we now saying donating unused things is inferior to donating things that could be used? I think this is a horrible take. Also two years since when? US had regular supply of vaccine only since March.
One important piece missing from this article is that on Vercel you do not get global Serverless functions on any plan except the Enterprise plans. By default you can pick one preferred region for your Serverless functions and that's the region that's always used. In practice, assuming you have a somewhat decent caching strategy, this doesn't really matter as far as latency is concerned. Where it could potentially matter is that AWS region having an outage and now you can't fallback to another. We deploy all our functions to at least two regions and Vercel does handle region failover in this case.
With Mux you can enable "Redundant Streams" (multiple CDN's used in HLS manifest) which I think solves the issue here. We are also a big Mux customer but admittedly haven't made the full switch to redundant streams, although our testing was very promising. Since their ingest is all GCP I don't think that was affected by this, and it would have just been delivery.
This is very wrong. I worked as an intern at WhatsApp in 2013 and they had over 30 employees, a lot were actually customer support. And “customer support” doesn’t do it justice. Every feature shipped was translated across 30 languages and CS was made up of people who could do a lot of the translation in house as well as provide actual support. I was an engineer on the website that dealt with all the support articles and translation, but the platform teams were all two engineers per platform, and then the backend engineers who worked magic with erlang.
I don’t think this works either because you can’t meaningfully agree on when light was emitted from one of the clocks. The only solution should involve a single clock but then you are always measuring 2 way and not 1 way speed.
That's like saying: Could you imagine having a function with many arguments and trying to find the return type?
Swift already uses the space at the end of the function declaration for things like throw and generic constraints. I personally don't see an issue with where it is other than I also write a lot of JavaScript and the context switching between languages might take a couple seconds.