Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: refactor to use interfaces #35

Merged
merged 14 commits into from
Jan 24, 2024
Merged

feat: refactor to use interfaces #35

merged 14 commits into from
Jan 24, 2024

Conversation

devanbenz
Copy link
Member

RFC:

  • By setting up the http server to allow for interface injection we can make it easier to unit test the queue system
  • Setting up logger as an interface makes it more extensible

@devanbenz devanbenz requested a review from lazyguru January 22, 2024 13:40
Copy link

github-actions bot commented Jan 22, 2024

Go test coverage: 2.7% for commit c64e257
View coverage for all packages
# Package Name                                | Coverage
+ sublinks/sublinks-federation/internal/lemmy |     2.7%

}
defer conn.Close()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should keep this one and remove the one on line 29. Better to call defer early

if err != nil {
log.Error("Error reading object", err)
s.Error("Error reading object", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's just me, but this feels really weird (essentially calling server.Error doesn't translate to "log an error")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good since I'm embedding the Logger interface I can either call s or s.Logger
Modifying it

func SetupPostRoutes(r *mux.Router) {
r.HandleFunc("/post/{postId}", getPostHandler).Methods("GET")
func (s Server) SetupPostRoutes() {
s.HandleFunc("/post/{postId}", s.getPostHandler).Methods("GET")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same thing here as the logging. server.HandleFunc just doesn't make as much sense. Maybe if it was server.AddRoute? When I see server.HandleFunc I think of adding a middleware, not a route

var body interface{}
rawbody, err := io.ReadAll(r.Body)
if err != nil {
Error("Error reading request body", err)
l.Error("Error reading request body", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On some of the methods where they are only a single line or two, I'm kind of ok with short variable names. However, as we get into longer functions it makes more sense to use more descriptive names. If we just want to make things simpler and say "always use descriptive variable names" I'd be fine with it also.

}

func Info(msg string) {
func (l Log) Info(msg string) {
log.Info().Msg(msg)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these all be updated to l instead of log?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep - gone ahead and updated this. The interface methods have the same names as the embedded zerolog package so its kind of verbose ie. logger.Logger.Info()

@devanbenz devanbenz requested a review from lazyguru January 23, 2024 12:51
@devanbenz
Copy link
Member Author

Made updates!

conn, err := db.Connect()
defer conn.Close()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I think the other line I commented on is better no? Shouldn't we check whether an error occurred before trying to defer closing? (not sure if the Fatal logger will still call deferred functions and cause more errors?)

}

func getActivityHandler(w http.ResponseWriter, r *http.Request) {
func (s Server) getActivityHandler(w http.ResponseWriter, r *http.Request) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can compromise and use srv for these? I really don't like non-descriptive variable names unless they are used in a for loop as an iterator (eg for i = 0; i < 5; i++ type stuff) or in methods with only a couple of lines (so it's easy enough to keep track of what the variable means. Even then, it would probably be better if we standardized and used better naming everywhere. I know I'm guilty of this with the request/response writer variables)

Copy link
Member Author

@devanbenz devanbenz Jan 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes absolutely. I know go devs tend to use single character vars but I much prefer verbosity. I'll change all the single char vars to "server"

@devanbenz devanbenz requested a review from lazyguru January 24, 2024 16:59
Copy link
Member

@lazyguru lazyguru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there

cmd/federation.go Show resolved Hide resolved
@@ -44,7 +42,7 @@ func getActivityHandler(w http.ResponseWriter, r *http.Request) {

break
default:
error.Error(fmt.Errorf("action %s not found", vars["action"]))
error.Error(fmt.Errorf("action %server not found", vars["action"]))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing you searched and replaced? This one should stay as %s.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep yep! just changed back

@devanbenz devanbenz requested a review from lazyguru January 24, 2024 19:29
Copy link
Member

@lazyguru lazyguru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@lazyguru lazyguru merged commit ba76425 into main Jan 24, 2024
2 checks passed
@lazyguru lazyguru deleted the update-http branch April 27, 2024 05:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants