You made a VCALENDAR generator with a web-accessible endpoint. It fills in the VCALENDAR with info passed in via URL parameters. And rather than returning a webpage, it just returns the VCALENDAR file.
So you send your friends the link, they click it, rather then returning text/html content, it returns a downloadable response consisting of a pre-filled VCALENDAR file with the correct MIME type, and .ics extension.
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.
"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.
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
Mmm yes, this one reminds me of the microservices debacle from a few years ago about when does your monolith technically become a microservice. I can't find the link, but I think we were unable to clearly define at which point your monolith has become a true 'SoA' group of microservices.
The generous interpretation of what op said is that you don’t have to maintain a server in any way or shape which is indeed the case. You only write business logic while the infrastructure automatically connects it to handle inbound requests.
Then I missed the point and your use case. I re-read your article and this is the only sentence where I believe I could have got it if I read it carefully enough:
> Now I can finally send my friends a link to a calendar event for our next pub crawl.
I suggest you update the tagline to say "link" as there is no "terminal" involved. That is, you don't use cURL and you don't send a normal calendar invitation email, but instead you send a message with a link that gives them the ical file when they click it.
Not sure I understand because that's what it is basically. The Rust part is just for the routing; it decides whether to serve the form or the generated calendar file.
What they mean is that instead of using "serverless" hosting running a rust program to generate ics files you could literally just have a statically hosted html file that uses a couple lines of javascript to generate the ics files within the browser, so there would be no rust or server component at all.
You could just host it with github pages.
Actually I'm confused why you're saying:
> The Rust part is just for the routing
Because it appears that you're generating the ics files in rust?
Got it. The generator logic is in Rust yes. I could have written it in JavaScript as well but it was just easier for me to do that part in Rust. Should have mentioned that.
Of course you could host a static HTML with JS on Github pages, but Github pages also runs on a server. So to answer the original question, yes you do need some server for it unless you make it a command line app.
/me glances at serverless in the title. Man, I would not want to have to technically design anything with you. You can't just say a thing is something and then say "oh well it's not actually but it could've been if I had made it entirely differently." ...
You can serve a static HTML page from anywhere. GitHub pages, S3, maybe even Dropbox. Running a Rust binary is an order of magnitude more complex than that.
Author here, had a lot of fun building this as it's just ~100 lines of Rust code + some CSS/HTML.
If someone is looking for a fun thing to contribute to during Hacktoberfest, the code is on Github: https://github.com/mre/zerocal
Will mainly use it for myself to send out event links to friends.
It's just Rust, so it can be. Will add a `main.rs` and some instructions, but PRs are welcome if someone beats me to it. ;)
https://github.com/mre/zerocal/issues/9
The process for making webapps in Rust seems extremely clean compared to other languages (or maybe I'm not exposed enough but I remember making things with Golang and even just JS was torture with common hosting solutions). Props to shuttle.rs and the Rust community!
I was using Heroku, but thinking back it may have been just a factor of inexperience (I don't do web much, not had I used Heroku before and the UX is not great there). I can't actually remember which go framework I used, but I associate negative feelings with the experience (take this entire thing with a grain of salt - I just thought shuttle.rs + the general rust buildsystem seemed so much cleaner than what I recall doing - I struggled a lot with config files and getting the module system to work for me)
> I wanted a way to create calendar entries from my terminal.
> There is no state on the server, it just generates a calendar event on the fly and returns it.
Didn't see that coming. I suppose it's handy that you can call it anywhere curl is installed (or even use the browser address bar as your command line) instead of having to install and run the Rust program locally.
Why do we need a vCalendar file generator? The output of your app is a vCalendar file which is then imported into a Calendar app either manually or through the integration of email and calendar services. So in the end, people still have to use a calendar app. It is much easier to create an event on a calendar app and send the invitation which is actually sending emails with a vCalendar file as an attachment. Besides that, most calendar apps allow exporting the event as a vCalendar file also.
Looks cool but...why not just send the .ics file directly via your IM of choice? Am I missing something here? I don't see the benefit if you still have to click, open file in your calendar, add it to the calendar.
Can you tell me why the above wouldn't work and why this is better?
You could do that but you'd have to create the ics file manually and not every platform allows you to share ics files. My original use-case was Github. Wanted to share invites for https://github.com/hello-rust/community. Github prevents sharing ics.
Another thing is that people could edit a link in-place to e.g. update the time without creating a new file.
Speaking of zerocal, have you ever noticed that low calorie packaged foods like pickles and cauliflower will put tiny serving sizes on the package so they can advertise 0 calories? I think they round down to zero when it's less than 5 calories.
Yep. Another suspect of this is cooking oil spray, like Pam. They can advertise very low calories, usually 0, per serving but a serving is considered like 1/3 of a second spray.
I'm wondering if this or a similar tool could be hooked into emacs to make working with calendars in emacs a bit easier. I don't think there is a good way to send calendar invites to people from emacs (but happy to be wrong on this one).
As seen in the article, the invites are simple text files. (I haven't tried, but you might be able to create one with icalendar-export-region?)
I think the more difficult part is sending an email that looks and works right with the invite attached in a way compatible with the receiving systems.
Invitations from Microsoft systems are especially horrible as they look like normal, plain text messages (without an invite) in standards-compliant systems. Depending how the sender expresses themselves, the receiver might have no clue they were invited let alone the time and place.
I seem to have missed the author's point which is to craft the link and send the link to others to download. This way, it doesn't matter whatsoever what software is used.
I guess. It’s just so lazy. If you’re making a cli tool, why is it curl with a hand crafted url? At least have a custom executable or script bunch of options so you have checks against misspelling “description”.
I want to make sure I understand this:
You made a VCALENDAR generator with a web-accessible endpoint. It fills in the VCALENDAR with info passed in via URL parameters. And rather than returning a webpage, it just returns the VCALENDAR file.
So you send your friends the link, they click it, rather then returning text/html content, it returns a downloadable response consisting of a pre-filled VCALENDAR file with the correct MIME type, and .ics extension.
Do I have that right?
That's correct.
Sorry but how is it serverless? Is it a static HTML file with JS that does the job? Isn't there a server that the request goes to?
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.
"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.
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
> 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.
And you may even use some 'serverless' DB services. Or not. The app is still serverless.
This can easily run on Cloudflare workers, you don't even need a server
... what do you think those are
this thread is making me feel like I'm going crazy
Mmm yes, this one reminds me of the microservices debacle from a few years ago about when does your monolith technically become a microservice. I can't find the link, but I think we were unable to clearly define at which point your monolith has become a true 'SoA' group of microservices.
The generous interpretation of what op said is that you don’t have to maintain a server in any way or shape which is indeed the case. You only write business logic while the infrastructure automatically connects it to handle inbound requests.
Isn't it serverless when it's local-only? Or, in an extreme case, peer-to-peer?
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.
Then I missed the point and your use case. I re-read your article and this is the only sentence where I believe I could have got it if I read it carefully enough:
> Now I can finally send my friends a link to a calendar event for our next pub crawl.
I suggest you update the tagline to say "link" as there is no "terminal" involved. That is, you don't use cURL and you don't send a normal calendar invitation email, but instead you send a message with a link that gives them the ical file when they click it.
Do you even need a service for this? Couldn't this be a simple static HTML + minimal JS that opens a base64 URL with content-type "text/x-vcalendar"?
Not sure I understand because that's what it is basically. The Rust part is just for the routing; it decides whether to serve the form or the generated calendar file.
What they mean is that instead of using "serverless" hosting running a rust program to generate ics files you could literally just have a statically hosted html file that uses a couple lines of javascript to generate the ics files within the browser, so there would be no rust or server component at all.
You could just host it with github pages.
Actually I'm confused why you're saying:
> The Rust part is just for the routing
Because it appears that you're generating the ics files in rust?
Got it. The generator logic is in Rust yes. I could have written it in JavaScript as well but it was just easier for me to do that part in Rust. Should have mentioned that. Of course you could host a static HTML with JS on Github pages, but Github pages also runs on a server. So to answer the original question, yes you do need some server for it unless you make it a command line app.
You need a browser and a file. In your example you need a server to make the file and and a browser.
True, but for others to resolve the calendar entries you'd need to serve that file somewhere.
/me glances at serverless in the title. Man, I would not want to have to technically design anything with you. You can't just say a thing is something and then say "oh well it's not actually but it could've been if I had made it entirely differently." ...
You can serve a static HTML page from anywhere. GitHub pages, S3, maybe even Dropbox. Running a Rust binary is an order of magnitude more complex than that.
Author here, had a lot of fun building this as it's just ~100 lines of Rust code + some CSS/HTML. If someone is looking for a fun thing to contribute to during Hacktoberfest, the code is on Github: https://github.com/mre/zerocal Will mainly use it for myself to send out event links to friends.
FYI: the text on your blog post is cropped on my small screen (iPhone SE), and scrolling doesn’t even help, so its essentially unreadable.
Thanks for the info. I thought I fixed that lately [1]. I don't have an iPhone to test it with but I'll see what I can do.
At least on the Chrome viewport emulator it looks fine to me...
https://github.com/mre/endler.dev/commit/bc1187d290d153455b0...
Not sure if it’s the problem, but MDN says Safari doesn’t support “overflow-wrap: anywhere”.
I’d actually never heard of overflow-wrap :)
Can it be self-hosted without relying on shuttle.rs? If yes, could you please update the readme with instructions?
It's just Rust, so it can be. Will add a `main.rs` and some instructions, but PRs are welcome if someone beats me to it. ;) https://github.com/mre/zerocal/issues/9
Update: self-hosting works now. Added instructions to the docs. Have fun.
The process for making webapps in Rust seems extremely clean compared to other languages (or maybe I'm not exposed enough but I remember making things with Golang and even just JS was torture with common hosting solutions). Props to shuttle.rs and the Rust community!
> I remember making things with Golang… was torture with common hosting solutions)
What made it difficult to deploy Go apps?
I did it around 2 years ago: the web solutions were not very mature and it was poorly supported (but that's my subjective experience)
What solutions were you using?
I was using Heroku, but thinking back it may have been just a factor of inexperience (I don't do web much, not had I used Heroku before and the UX is not great there). I can't actually remember which go framework I used, but I associate negative feelings with the experience (take this entire thing with a grain of salt - I just thought shuttle.rs + the general rust buildsystem seemed so much cleaner than what I recall doing - I struggled a lot with config files and getting the module system to work for me)
We have come a long way since Heroku. Vercel/Zeit has really raised the bar and expectations for a modern PaaS.
Noted, thanks, I'll check them out!
I’m also curious - could you maybe give an example of something concrete that is (or was) difficult in go but easy with rust?
What do you mean by web solution? Go ecosystem is mature in that field and it's very easy to deploy.
> I wanted a way to create calendar entries from my terminal.
> There is no state on the server, it just generates a calendar event on the fly and returns it.
Didn't see that coming. I suppose it's handy that you can call it anywhere curl is installed (or even use the browser address bar as your command line) instead of having to install and run the Rust program locally.
I seem to have missed the author's point which is to craft the link and send the link to others to download.
Why do we need a vCalendar file generator? The output of your app is a vCalendar file which is then imported into a Calendar app either manually or through the integration of email and calendar services. So in the end, people still have to use a calendar app. It is much easier to create an event on a calendar app and send the invitation which is actually sending emails with a vCalendar file as an attachment. Besides that, most calendar apps allow exporting the event as a vCalendar file also.
Looks cool but...why not just send the .ics file directly via your IM of choice? Am I missing something here? I don't see the benefit if you still have to click, open file in your calendar, add it to the calendar.
Can you tell me why the above wouldn't work and why this is better?
You could do that but you'd have to create the ics file manually and not every platform allows you to share ics files. My original use-case was Github. Wanted to share invites for https://github.com/hello-rust/community. Github prevents sharing ics. Another thing is that people could edit a link in-place to e.g. update the time without creating a new file.
Speaking of zerocal, have you ever noticed that low calorie packaged foods like pickles and cauliflower will put tiny serving sizes on the package so they can advertise 0 calories? I think they round down to zero when it's less than 5 calories.
Yep. Another suspect of this is cooking oil spray, like Pam. They can advertise very low calories, usually 0, per serving but a serving is considered like 1/3 of a second spray.
And it’s literally aerosolized oil, so definitely not a calorie-free food!
I'm wondering if this or a similar tool could be hooked into emacs to make working with calendars in emacs a bit easier. I don't think there is a good way to send calendar invites to people from emacs (but happy to be wrong on this one).
As seen in the article, the invites are simple text files. (I haven't tried, but you might be able to create one with icalendar-export-region?)
I think the more difficult part is sending an email that looks and works right with the invite attached in a way compatible with the receiving systems.
Invitations from Microsoft systems are especially horrible as they look like normal, plain text messages (without an invite) in standards-compliant systems. Depending how the sender expresses themselves, the receiver might have no clue they were invited let alone the time and place.
I seem to have missed the author's point which is to craft the link and send the link to others to download. This way, it doesn't matter whatsoever what software is used.
I beg you to keep GET requests idempotent. It's not that hard.
There’s no state maintained on the server, so all requests made to it are idempotent.
Maybe I am missing something, but which GET is not idempotent?
Don't be a party pooper. This is just RPC via HTTP. ;)
Given that this just creates an ics file, why bother with a server at all?
Apparently, to craft and send the link rather than the file.
I guess. It’s just so lazy. If you’re making a cli tool, why is it curl with a hand crafted url? At least have a custom executable or script bunch of options so you have checks against misspelling “description”.