Feature user register#7
Conversation
Exported variables should be named using PascalCase. Since I used `GORM` for modeling, I need a database connection. It uses `sql.DB` under the hood, so when I close `sql.DB`, I automatically close the `GORM` connection as well.
This is quite a large commit—sorry about that! That said, most of the changes are related to restructuring the folder layout, which I believe is a crucial improvement. I’ve decided to stop overthinking the project structure and went with something scalable, even if it's a bit overkill for now. I’ll explain more in the PR description. Also, I’ve introduced error handling via middleware.
- I also tried to improve error handling. - Typo: `ErrUserExists` → `ErrUsernameExists`
Vasilijez
added
the
feature
|
Why are my commits part of this PR? Did you do this e156f37 manually? |
|
Honestly, I don't know, maybe I accidentally created the |
There was a problem hiding this comment.
As far as the project structure goes, I think it's overengineered. There's no need to package by layer for such a small service. Also, do we really need a struct for each layer? I would've written everything as a function. So, registering users would be HandleRegister(), Register(), DBRegister(). I think that's closer to idiomatic Go. We don't want another MockerHub that's trying to be like Spring Boot.
It doesn't matter. Don't change it now, we would just be wasting time. I want to finish everything ASAP.
I didn't test it manually yet because we have no frontend nor a simple python script (like a import requests; requests.post("...", {...}), and the Address model is needlessly complex.
We could add a backoff, but I think it's smarter to keep retrying indefinitely without delay, since we want all services to start as soon as possible.
I made this change based on our specification, as we likely won’t need more than one service or repository.
I was unsure about the `Register` handler and decided to make it lowercase, as I currently don’t see a reason to export it. Integration tests will likely be performed via API calls.
|
I applied the following method for resolving the I created the All previous commits remained unchanged and have the same hash values. All the commits I copied have new hash values. The If I went with the The simplest methods, like changing the base branch from |
2 participants
I have introduced the following project folder structure. It is a little overcomplex, but I couldn’t overthink it anymore. If you don’t like this organization, I am ready to make changes. I remain flexible to make any necessary adjustments.
Files like
handler.go,route.go,service.go,repo.gocan become folders and be split into multiple files such asauth_service.goanduser_service.go. But they can also stay as they are, thanks to the simplicity of our microservice.The
middlewarefolder can be populated with components such as logging, metrics, and others.The
configfolder can contain all configuration files, like database settings and others.I started writing tests in the test folder based on feature names, as this seemed like the best approach from my point of view.
I don’t have much to say about implementing user registration. It is CRUD.
I attempted to implement centralized error handling using
error_middleware.go. It will intercept all HTTP requests and add HTTP status codes based on the errors. It also centralizes log data. For customized errors, it is handy to sometimes wrap them with additional data usingfmt.Errorf.