[omn1]

Good question. It depends on your definition of serverless. Strictly speaking there is no serverless, there's always some infrastructure somewhere.

However the calendar file gets created out of thin air from the GET parameters alone. There is no state or storage involved. Other calendar apps have a backend with a DB; this one doesn't. Now whether that counts as truly serverless is up to you I guess. It's as close as you could get with a calendar I'd say. Not easy to get the point across in a title. ;) Hope that helps.

[actuallyalys]

"Stateless" is probably clearer. "Serverless" usually refers to services from cloud providers where your code is run on demand rather than having a server that is idling around (to use a sibling comment's phrase). I don't really care for "serverless" as a term because there are still servers (as you point out) and there are other architectures and cloud services that seem equally serverless that aren't usually called that.

[jethro_tell]

serverless is when you save the state but don't keep a machine sitting around when there are no requests, so you'd keep your calendar state in a hosted db and when someone asks for the calendar, a thread spins up and creates the calendar from the state and then disappears until there is another request. This is basically the exact opposite of serverless

[rustyminnow]

> serverless is when you [...] don't keep a machine sitting around when there are no requests

FTFY

The key part of serverless is that you don't have a server idling around. Whether or not you use a hosted db is not relevant.

[drexlspivey]

This can easily run on Cloudflare workers, you don't even need a server

[rhn_mk1]

Isn't it serverless when it's local-only? Or, in an extreme case, peer-to-peer?

[Thaxll]

Your app is always running to answer those GET so it's not serverless. Serverless means that your rust code would be invoked upon GET.