Code structure and development enhancements

[rslabbert]

I've created #26 which makes some logging changes and I've alluded to some broader code structure changes I can spot as worth doing, I thought I'd list them out here just so it all makes sense:

• Linting: My first step was to integrate golangci-lint as part of the CI process to test against some of the code smells that are easy to make in Go otherwise
• Logging (Add a rudimentary logger and convert logging calls across codebase #26): As part of the linting, there were some changes around the use of fmt that needed to be made, and starting with a dedicated logger want a good starting point for that
• Migrations: The current code has a structure for migrations, I was planning on rounding that out and making it functional
• Structural: This will deserve its own issue to discuss, but there are some folder/code structure changes that can be made which will make it much easier to navigate and use the codebase
• Reliability/robustness: The current code can use some edge case and reliability love. This isn't a bad thing, I think it just takes a bit of time to get this stuff running that is often better spent on features, but I can probably add value in.
• Testing: Automated tests, particularly fuzzing tests will be good to add in to ensure things are working as expected.
• API: The structural changes and testing should make adding an API layer a pretty simple endeavour

[cblgh]

thanks for this issue @rslabbert!

linting / structural are things I am wary of. Out of all the bullet points, I think the migrations is something I'd love to see some support for (maybe the database package but separate from the logic in database.go)!

are you open to starting something really small on that topic, and opening a PR, so that I can see that "hey this aligns with what 1) i understand (lolol) and 2) how i think it would be reasonable for it to impact other parts of the project"

re 2) ideally the impact would be as smol as possible!

again: smol steps first and then if alles gut let's go full-steam ahead! Already feel bad for the PR you sent in already, so would really want to avoid you doing any work that doesn't make it into the forum.

all the best

~cblgh

oh p.s. another thing that has been kinda top of mind since @randrew requested it over irc would be a json endpoint for interacting with the forum, so that someone could ideally implement a completely separate for the forum using it. some quick sketches or ideas on that front would be really dope if the migration doesn't work out

[rslabbert]

@cblgh

Hey mate,

Regarding migrations, my plan was to follow this code, let me know if that aligns with what you're looking for: https://github.com/miniflux/v2/blob/master/database/migrations.go

Regarding the rest, that totally makes sense in terms of small changes. The initial value I saw being able to contribute appeared to be more in these higher level pieces, but I'm not wedded to this in the slightest!

If I start looking into any of the other pieces I'll start with a new issue that's small and scoped to review first.

Cheers!

[cblgh]

@rslabbert yeah that migration solution looks great! after we have it in, i'll probably make use of it immediately to add support for community-only threads (TABLE threads is lacking a private boolean atm)

looking forward to it :3