gqlgen lets you define the schema externally in a schema file, and also generates a strongly typed interface for us to implement against. And apparently it performs better.
Start implementing directives
The first one is a @hasAuth directive that marks a GQL query or mutation as requiring authenticaiton.
Moves everything except game logic and models into the root package.
I realize now that I haven't really been writing golang code like golang code should be written. We should highly prefer throwing things into a single package until it makes sense to break them out, vs. trying to model the entire problem domain in packages from the beginning like you would in other languages. This makes testing much simpler.
Changes the db model
So, I changed up the DB model in a few ways.
Split up Identities and Users.
This one I'm not 100% sure how I feel about. I split things up into Identity, which contains login / account information (email, password), and User, which contains player profile (name, etc). information. So I'm playing with the idea of splitting these up in the database as well, because that allows us to eventually decouple users from accounts; this lets people create and play with multiple accounts (with different ranks). This is a common practice on other servers and so giving us the flexibility to support that as a feature is kinda interesting.
On the GQL side, separating identities from users makes a great deal of sense. Identities probably shouldn't actually be ever exposed to anyone except the authed user. Users are public profiles and can be exposed to anyone.
Games and users are a one-to-many relationship
Games have states: invitation, in progress, finished
Games have types, currently a standard game is the only one. Maybe rengo for the future
At this point everything builds and works and is tested. We now need to reimplement the game logic mutations, add a game serialization format, etc.
This is a big one;
Changes the Graphql library to gqlgen
gqlgen lets you define the schema externally in a schema file, and also generates a strongly typed interface for us to implement against. And apparently it performs better.
Start implementing directives
The first one is a
@hasAuthdirective that marks a GQL query or mutation as requiring authenticaiton.Moves everything except game logic and models into the root package.
I realize now that I haven't really been writing golang code like golang code should be written. We should highly prefer throwing things into a single package until it makes sense to break them out, vs. trying to model the entire problem domain in packages from the beginning like you would in other languages. This makes testing much simpler.
Changes the db model
So, I changed up the DB model in a few ways.
Identity, which contains login / account information (email, password), andUser, which contains player profile (name, etc). information. So I'm playing with the idea of splitting these up in the database as well, because that allows us to eventually decouple users from accounts; this lets people create and play with multiple accounts (with different ranks). This is a common practice on other servers and so giving us the flexibility to support that as a feature is kinda interesting.On the GQL side, separating identities from users makes a great deal of sense. Identities probably shouldn't actually be ever exposed to anyone except the authed user. Users are public profiles and can be exposed to anyone.
At this point everything builds and works and is tested. We now need to reimplement the game logic mutations, add a game serialization format, etc.