Convert to using Gin and (greatly) simplify

[justinclift]

This PR was mostly because I needed a practise project to get the hang of Gin with.

Updating/simplifying this project has been on the wish list for ages anyway, so it's not wasted effort. 😄

[justinclift]

@MKleusberg Converting this Gin. So far it's not too bad, though Gin's docs aren't very good. 😦

[justinclift]

@MKleusberg Oh, I've removed the TLSNextProto line when I copied the http.Server piece from the DBHub.io API main.go:

https://github.com/sqlitebrowser/dbhub.io/blob/5f902c78e195839becbe59be041b336383ae4b51/api/main.go#L158

That line seems to be for disabling HTTP/2 support, which I think is to stop the HTTP/2 Rapid Reset attack from working.

Go releases from 1.21.3 onwards aren't susceptible to that attack, so won't affect us.

If that was disabled for some other reason though, then please let me know as we might need to still disable it after all. 😄

[justinclift]

@lucydodo @chrisjlocke Not sure if you're interested in reviewing Go code, but just in case you are then I'd welcome your input. 😄

[lucydodo]

Thanks for the opportunity, but I don't know enough about Go to comment. :(

[justinclift]

No worries at all. 😄

[justinclift]

Doesn't looks like anyone's around to review this, so I'm just going to merge it rather than leave it hanging around. 😄

[justinclift]

This is deployed to production now, and seems to be operating ok. 😄

[MKleusberg]

Just had a first closer look and seems all good so far 😄

Three questions popped up though:

1. Is the fallback SQLite connection really worth the effort, like would we really merge the data into the actual database afterwards? And what about the connection breaking while this is running, so during startup connecting to Postgres but then having to switch to SQLite later. Or is the SQLite backend maybe just for testing purposes?
2. Looking at it now I fell like moving all the download files information (file names, dates, etc.) into a database table so this is more data driven.
3. Would setting the last modified date on the files at startup be an option? So we make sure they have the correct last modified dates and from there on we could use StaticFile or ServeFile? Besides potentially simplifying the code, these function reduce copying by using the sendfile syscall.

And one final thing:
We could/should remove the CORS middleware from this. Besides that one line of code it would also get rid of one dependency. But more importantly I don't think Access-Control-Allow-Origin: * makes a lot of sense here.

[justinclift]

Thanks for looking over it. 😄

what about the connection breaking while this is running

Haven't tested it, so it could be anything from "silently dropped" to "application aborts and is restarted by systemd, which then records to a database". The 2nd one would be better, but I really have no idea yet what the actual behaviour is. 😄

I was more doing it because we had a case of this happening a while back, where it ran for a substantial amount of time (months?) without recording anything. My intention there is that we can at least capture the data, and then figure out if we want to feed it back into the main database.

Yeah, it's kind of half arsed for now. 😇

2 - Heh. I hadn't though of putting that info into a database instead, but yeah... that would be doable too.

3 - Yeah, that'd probably be workable too. Just didn't think of it. 😄

---

I've just pushed a commit to master that removes the CORS middleware, and deployed the updated code to the production server.