crofu is a platform designed to test out incremental converse crowdfunding.
Databases
Databases have been a new thing that I've had to learn for crofu. I've got a lot of experience in static webdev (mostly from this wiki), but I wasn't able to think of a good way to implement crofu as a static site. It seemed like even the very bare minimum implementation of crofu would require a web API backed by some sort of database.
On the other hand, making the decision to just make a dynamic website has saved me a lot of weird mental gymnastics I otherwise would've had to do. Accounts and login? Just stick em in the database. Fediverse integration? Database. How do I securely generate page layouts? Load from the database client-side. API? Just a thin wrapper around the database. I can see now why web developers are the way they are: everything is just so easy when you give up on performance and simplicity.
Right now, I'm using Postgres. I don't remember why, I think someone just recommended it at some point and I just haven't run into any issues with it. Some aspects of SurrealDB seemed cool, but I really don't trust the project, and it seems like it would've been a hassle to use.
NOTE: everything below this line is outdated. I'm now using axum.
Web development has historically disgusted me. So many frameworks, so much cruft spread across various W3C standards, so much to know about, and an unappealing problem space. That, combined with cultural elements of corporate minimalism, the rise of Elektron-based webapps, and the infamous "move fast, break things" approach have kept me mostly in the realm of desktop and embedded software. Which isn't to say I've never made a website. In fact, some of the earliest software I've ever made were websites (the actual earliest are probably games, but the timeline is hazy and the definition can sometimes be blurry).
One of the projects that's been on my frontburner recently is incremental converse crowdfunding. This is one of the few projects I've worked on that practically requires a dynamic website. I considered implementing it with email, or ActivityPub, or a TUI that connects to a REST backend, but while none of those would require a web frontend, I think it would be a challenge to make them comfortable for a non-technical audience to use, and since I have to use web technologies anyway, might as well just make a regular website.
I've been putting off actually working on it, out of a fear of certificate authorities, nginx, DDOS attacks, authentication (especially password storage), and handling money, just to name the big ones. But a friend recently made a website where he plans to sell software directly to his customers (rather than through Gumroad, which is what he currently uses). Software politics aside, it was interesting to me that he was doing this because it seemed pretty slick, and he seemed to lack the fear that I had with my own website. I assumed this was based on the fact that he was using a bunch of existing services and frameworks, and the part of his stack that caught my attention was Supabase. I eventually realized that it didn't actually solve most of the more prominent issues I was worried about, but at the time, the particular features of Supabase that seemed appealing to me were that it handled authentication, had a free tier, and was self-hostable.
Currently, I use Rocket for my entire stack. I initially started with Yew, before realizing that it's intended for frontends. I might return to it later if I figure out that the frontend is actually something where I need to have a lot of dynamic stuff going on, because under no condition am I going to write any JavaScript or TypeScript.
Without a cloud service like Supabase, my options are pretty limited. Either I can roll my own authentication (almost certainly a bad idea, if years of pwns are any indicator), or I can hook into an existing website's authentication, through something like OAuth. One such standard that came up in my research was IndieAuth, which, as I understand it, runs on top of OAuth to log people into sites using their logins from, for example, their social media accounts. This is an improvement from OpenID Connect, which requires each website to explicitly allow logins from each provider it chooses to support. Twitter used to support it, but after the API closures, it no longer works. There are some smaller tools listed on the IndieAuth website, including a plugin for WordPress, but the biggest IndieAuth provider is probably GitHub. I think moving forward, Fediverse projects will probably start to support it, but right now, support for IndieAuth is pretty sparse. That being said, it seems to be my best option at the moment.
to be continued