Research: Initial implementation for saving metadata, application state, etc.

[atc0005]

As noted on GH-13, there are already strong leanings toward using a database to track events, even for short-term use (e.g., to identify when a temporary IP block should be removed). To that end, I think we'll need to identify a database backend and start designing a database schema to support our goals.

[atc0005]

I don't have a lot of experience with db design, nor properly/programmatically handling migrations between schema changes, so any initial implementation will be just that, a first stab at the problem with the hope that someone more skilled can step in later and rewrite/replace, or at the very least, extend the initial work to be easier to use.

For the purposes of simplicity, I'm thinking of a file-based database like SQLite. I have some experience with using it in the past for smaller tools and there seem to be a number of available guides for Golang/SQLite, so this could be our first step.

[atc0005]

Some potential resources:

• https://astaxie.gitbooks.io/build-web-application-with-golang/en/05.3.html
• https://github.com/mattn/go-sqlite3
  • https://github.com/mattn/go-sqlite3/blob/master/_example/simple/simple.go
• https://github.com/johnpili/golang-sqlite
• https://johnpili.com/golang-sqlite-simple-example/
• https://www.reddit.com/r/golang/comments/96yd0t/gosqlitelite_a_new_light_weight_sqlite_package/
  • this covers thread-safe concerns, concurrency, read/write locks, etc
• http://go-database-sql.org/index.html
  • general SQL guide/tutorial material
• https://www.bogotobogo.com/GoLang/GoLang_SQLite.php

Note: Whatever guide/direction I go, I'm looking to stick with the standard library database/sql package so that we will have the potential to fairly easily swap to another database backend (e.g., MariaDB) if we need to centralize the data for other purposes (e.g., central backups).

[atc0005]

Note: I have a real-world use-case for testing Go/SQLite, so I may take on that project in order to get more familiar with Go/SQLite before pushing hard on this.

[atc0005]

As noted on GH-13, there are already strong leanings toward using a database to track events, even for short-term use (e.g., to identify when a temporary IP block should be removed). To that end, I think we'll need to identify a database backend and start designing a database schema to support our goals.

As of #13 (comment) I'm thinking that a database might actually not be required for the initial implementation. I think a later version of this app could certainly benefit from extensive logging of metadata (managed by some sort of automated purging or sanitization of privacy-related details), but reducing the TODO list for the first implementation would help us get this ready for testing/proving a lot faster than waiting on this.

In short, it's probably best to place this on the back-burner for now.