💾 Archived View for matthiasportzel.com › gemlog › one-day-gemini-server captured on 2023-01-29 at 02:40:32. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-17)

-=-=-=-=-=-=-

A Gemini server in one day

I spent today writing a Gemini server.

I wanted a Gemini server for this website that was written in node.js so that it could integrate with the existing code that I've written for the Next.js (HTTP) part of this website. And perhaps more importantly, I needed a Gemini server that supported domain-name-based virtual hosting with different certificates per domain. And there's no Gemini server that I could find that checks these boxes.

I shouldn't pretend that I didn't have other options. I probably could have and should have used gemserv to call to a CGI file written in node. I've used Jetforce in the past, which supports CGI (or just Python hooks). I could have forked it and added support for multiple certificates, and perhaps I should have. Or perhaps I should have re-organized my Let's Encrypt certificates to all be on a single certificate.

Anyways, the point is that I was more motivated to write a server myself than to do any of those things. So here we are.

I probably worked on it for 10 hours, 11am to 10pm, with some time to eat. (And a lot of time pacing around thinking. I wasn't sitting still for 10 hours, I took several walks.) In that time I was able to impliment:

It was definietly motivated by my expericences with Next.js and Django, which have been more favorable than Apache. I tend to prefer this "hands-off framework" approach over the more traditinal Apache-style web-server. So rather than pointing it at a folder, you have to "register" indiviual paths that point to indiviual files. Since you configure it by editing a node.js file, you have a lot of flexibility, and can write your own handlers. If I continue working on it, I'll add more complex handlers, like the ability to mark a whole directory to be served as static, or reverse-proxy a path.

Honestly, I was very impressed with the node.js standard library. Although I've had issues with it in the past, its support for TLS and the SNI extension made this easier than I expected it to be.

It's a pretty barebones implimentation of what could grow into a very fancy, complicated Gemini server. But at the present time it doesn't make sense for me to open-source it, since it doesn't provide much advantage over clients that were designed to be simple.