Project Restructure #78
Conversation
to rebase is to feel pain this is going away too added tests, added local store i'm gonna rebase
|
Gonna have to figure out CI cause we need a test environment but don't track a normal |
| // Maybe we shouldn't use the increment ID but generate a UUID instead to avoid | ||
| // exposing the amount of users registered in the database. |
There was a problem hiding this comment.
Yeah we're doing UUIDs if we can. Issue for the future :)
|
I dig this structure. Maybe when I'm more awake tomorrow I'll also try figuring out how to get tests to work, if you don't already do by then. Then I'd like to see this merged :) |
There was a problem hiding this comment.
I like this article on structuring Go Code. I'm not generally a big fan of "common" because I think it means that code architecture hasn't really been properly planned out. It feels like a dumping ground for "stuff I need multiple places, but organized my other packages poorly."
Further, I don't understand why ping_test exists but we shoved all the database testing inside database.go
I'd like to see tests on server and users instead of just saying "it's hard", though, or at least a testing plan and issues/tasks drawn up for creating them.
(Also to reiterate: this is an improvement, I think this is good.)
Moved the stuff from common package into dedicated spots. DataStore interface moved to database, SuccessResponse stuff moved into a new package called request.
The original purpose of the package, to serve as an example for other package layouts, is largely obsoleted by the existence of the users package.
When I did the project-wide rename of the functions in the database package, I didn't save the files that had stuff renamed.
* Fix yaml syntax * we actually need the .env file * Rename solution We're not a POC anymore!
The number 1 thing I wanted to accomplish with this restructuring is to co-locate relevant code. We had a discussion about it further up about a month and a half ago, when I think robotmayo posted an open source google project that showed this style. I've since seen it a number of times as well. The server package could maybe be moved to internals as well.
With this, the new idea is to have each package sort of represent one data model in our API, i.e. users games runs what have you. In each package:
The tests I have here are much better than the open PR. They use helpers in a nicer way, make use of t.Parallel() and are table based. They also use the real database connection.