This is part 3 of a series on design decisions I've made in my proposal for how The 1024 Club should work.
The original plan for The 1024 Club was to use the Python async web framework "sanic" to handle connections, with the Python library "databases" offering asynchronous access to the database underneath. However, after struggling through documentation hell with cryptography (as documented in the previous The 1024 Club post), it wouldn't take much for me to switch gears if documentation was lacking and frustration arose.
As it turns out, the breaking point was whether a function returned an error or not.
Part of the registration process (as I envisioned it) was making sure we didn't already have an entry for a given public key. In any normal circumstance, this would be the easiest thing to do. All you would need to do is check whether a search for the fingerprint in the database returned a result or not. However, the library we were using didn't document what happened if the query didn't return a value. After trying (and failing) to get asyncio set up, I said "fuck it" and sat down to work with Flask and Flask-SQLAlchemy. Actually, I said:
02:48 < khuxkm> i'm just gonna rewrite this shit in flask
02:48 < khuxkm> fuck asynchronous programming, fuck shitty documentation, fuck all of that shit
Within 30 minutes, I had a working server in Flask. The main thing I believed would be a sticking point was actually not an issue; request methods are actually easier to handle in Flask than I remember them being. The main thing to remember is that all of the methods you support need to be declared in the app.route call.
After implementing the Create and Read of CRUD (Create, Read, Update, Delete), I decided that the Update and Delete would best be left to a rested me, and decided to call it a night. When I wake up later today (it's 3:48 AM as I write this), I'll get to work on the update and replace, if gbmor hasn't beaten me to the punch and done it while I was sleeping. :P