Feat/dto models

[GaballaGit]

This PR introduces DTO models for the API. Currently there are 2 different ones, request and response. At the moment they are both similar, with the only difference of request having an extra Update Model since many more fields don't need to be inputted for an update. Response DTO model might be updated later depending on what we want the user to receive.

This PR also makes make check and make test a little more pretty.

[github-actions]

godoc reference preview ready ✨

[GaballaGit]

@TheJolman

[TheJolman]

models look clean. TBH I don't understand adding go build to the check step, can you revert that commit to keep this PR focused? Also can you check out https://github.com/go-playground/validator ? I think it would be very useful here. Gonna test this a little more locally and get back to you with more feedback.

[TheJolman]

Also can you organize it like internal/dto/announcements.go and have both request/response dtos in the same file just to reduce the amount of files that we're going to have. When doing this you should name them like UpdateAnnouncementRequest and UpdateAnnouncementResponse to avoid name conflicts (I think the current naming would create some). Also I dont think you need to create a base Announcement or Officer dto for now, as the response payloads should contain all fields anyways. You can keep them if you want, just rename them to AnnouncementDto or something bc the generic Announcement will likely create naming conflicts.

[GaballaGit]

holy shit what did I do

[TheJolman]

holy shit what did I do

dude idk its fucked tho lol

[TheJolman]

Can you also implement these new DTOs in at least one handler? I don't think it will make this too big and will let us verify they actually work. @GaballaGit

[GaballaGit]

I gotchu

[GaballaGit]

Okay now implementing in, I don't know if I make a handler use dto model in this pr @TheJolman . My reasoning is that, currently our handler calls a service that depends on a db model, that itself isnt bad, but then the service calls the database layer with the dbmodel, meaning that the repository layer must be implemented to test this, and with this also comes the mapper. I have tested the dto models in the other PR #159, where announcements has achieved functionality with DTO, Repository, and Domain models all together.

[TheJolman]

Okay now implementing in, I don't know if I make a handler use dto model in this pr @TheJolman . My reasoning is that, currently our handler calls a service that depends on a db model, that itself isnt bad, but then the service calls the database layer with the dbmodel, meaning that the repository layer must be implemented to test this, and with this also comes the mapper. I have tested the dto models in the other PR #159, where announcements has achieved functionality with DTO, Repository, and Domain models all together.

What I had in mind is having the handlers use the DTOs and then just translating them to dbmodels before calling the service. This isn't going to be the final form obv but it keeps it fairly atomic.

[GaballaGit]

@TheJolman what happened?

[TheJolman]

@TheJolman what happened?

mb was deleting stale branches from my cli and accidentally hit this

[TheJolman]

looks good ty!