Hurtki/git 32 username case

[hurtki]

Changes

Username cases bug fix

Before in out system were a lot of problems with username case:

• long-term banners. When someone was creating a banner, it was created with username user sent to server. And user could create banners with hurtki and HURTKI. And they were updating both.
• stats service. Stats service had case sensetive cache and repository, that led to going fetching data instead of taking it from cache or db
• important, that db was always containing correct username ( from github fetcher. ) So all requests to db with not correct username ( with wrong case ) were failing.

How I fixed this:

I clearly set, that domain logic shouldn't know about normalization, but all repos/infrastructures/caches it uses, should work with any case.
So, I refactored:

• repo level ( username_normalized/owner_username_normalized fields )
• cache level ( preview cache to use lower case for key computing and stats cache to use lower case as cache key )
• infratsructure level ( github fetcher already works with any case )

Postgres tables changes:

Create github_data schema to separate github information from our service's data ( users table was very confusing )

users -> github_data.users
repositories -> github_data.repositories

users:

before:
username text primary key

after:
username_normalized text primary key
username text not null

repositories:

before:
owner_username text not null

after:
owner_username_normalized text not null

banners:

before:
github_username text not null + unique ( github_username, banner_type ) 

after:
github_username_normalized text not null + unique ( github_username_normalized, banner_type ) 

As standart I decided to use lower() function every time I can, when inserting, selecting data using sql.
It removes a bit load from go serivce and standardizes normalization place.

HTTP handlers

Clear response errors defined in handlers

Now, handlers, when recognize error, are not using err.Error() for http response. they determine it themselves.
Example:

...
		switch {
		case errors.Is(err, preview.ErrInvalidBannerType):
			h.error(rw, http.StatusBadRequest, "invalid banner type")
		case errors.Is(err, preview.ErrUserDoesntExist):
			h.error(rw, http.StatusNotFound, "user not found on github")
		case errors.Is(err, preview.ErrInvalidInputs):
...

With this approach domain logic ( usecases ) can be not afraid of wrapping infrastructure or any other error before returning it.

Start of docs

I by my hands started writing docs of api ms in architecture.md, I highlighted, in my opinion, the most important points, and I will continue to do so in new PRs.
Fully updated api.yaml file, accoring to current api.
Deleted manual.md, еhere were a lot of confusing things there. This service can be run separately from the others, but it's not as convenient as running everything together in Docker Compose. It might be reworked in the future.

Also global repo README.md should be reworked in near future.

[R7rainz]

for j := i; j < i+8; j++ {
	tempPosArgs = append(tempPosArgs, fmt.Sprintf("$%d", j))
}

i think this part can be shorten by this

[hurtki]

I mentioned it in PR description, I wanted to lower it only in sql:

As standart I decided to use lower() function every time I can, when inserting, selecting data using sql.
It removes a bit load from go serivce and standardizes normalization place.

---

I got intresting approach in my head:

As, I understand it's better to have one function in project for username normalization.
And use it from everywhere, but I thought it was a problem to use it in migration.
But, eventually goose has ability to create .go files migrations, where we can use our unified function.

Let me know, what do you think, with this approach we can get rid of lower() functions in SQL.

[R7rainz]

yea this is a more modular approach and makes sense with our project architecture as well

[hurtki]

fine, starting working on it

[hurtki]

@R7rainz, check out latest commits

I moved two migrations into go format, where used unified function to normalize columns.

Now NormalizeGithubUsername is used all over the project.