21–30 of 64 posts
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!
What made it difficult to deploy Go apps?
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 co…
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"?
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 co…
That's correct.
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?
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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…
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?
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.
Earlier quoted context omitted.
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…
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