Add solution for gin challenge-1-basic-routing by Mxn-ptr

[Mxn-ptr]

gin challenge-1-basic-routing Solution

Submitted by: @Mxn-ptr
Package: gin
Challenge: challenge-1-basic-routing

Description

This PR contains my solution for gin challenge-1-basic-routing.

Changes

• Added solution file to packages/gin/challenge-1-basic-routing/submissions/Mxn-ptr/solution.go

Testing

• Solution passes all test cases
• Code follows Go best practices

Thank you for reviewing my submission! 🚀

[coderabbitai]

Walkthrough

Adds a new Go file implementing an in-memory Gin-based REST API for User resources, defining models, an in-memory store, validation, and handlers for CRUD and name-based search under /users.

Changes

Cohort / File(s)	Summary
Gin in-memory Users API packages/gin/challenge-1-basic-routing/submissions/Mxn-ptr/solution.go	Introduces User/Response types, in-memory storage, validation, and Gin routes/handlers for GET/POST/PUT/DELETE /users and GET /users/search.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant C as Client
    participant G as Gin Router
    participant H as Handler
    participant V as Validator
    participant S as In-memory Store

    C->>G: POST /users {name,email,age}
    G->>H: Route to createUser
    H->>V: validateUser(payload)
    V-->>H: validation result
    alt valid
        H->>S: Append user, assign nextID
        S-->>H: Created user
        H-->>G: 201 {success,data:user}
        G-->>C: Response
    else invalid
        H-->>G: 400 {success:false,error}
        G-->>C: Response
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Add solution for gin challenge-1-basic-routing by Johrespi #836: Adds an almost identical Gin-based in-memory User CRUD API with the same types, routes, and helpers.
• Add solution for gin challenge-1-basic-routing by AlexO-85 #708: Introduces the same Gin Users REST API structure including User/Response types and CRUD/search handlers.
• Add solution for gin challenge-1-basic-routing by aroquega-codes #1087: Implements a similar in-memory Gin User API with matching handlers and helper functions.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: adding a solution submission for a specific Gin challenge by a specific author.
Description check	✅ Passed	The description is directly related to the changeset, identifying the challenge, author, and files added.
Docstring Coverage	✅ Passed	Docstring coverage is 88.89% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@packages/gin/challenge-1-basic-routing/submissions/Mxn-ptr/solution.go`:
- Around line 156-164: The partial-update logic uses the zero value check
input.Age != 0 so an explicit {"age":0} is ignored; change the input DTO to make
Age a pointer (e.g., *int) and update the handler to check input.Age != nil and
then set user.Age = *input.Age (leave Name/Email checks as-is), and ensure the
JSON binding tags on the input struct allow distinguishing omitted vs provided
fields.

🧹 Nitpick comments (2)

packages/gin/challenge-1-basic-routing/submissions/Mxn-ptr/solution.go (2)

39-45: Variable shadowing and route ordering concern.

The local variable users shadows the package-level users slice, which can cause confusion during maintenance. Consider renaming to userRoutes or similar.

Also, while Gin's router correctly prioritizes static routes over parameterized routes, it's conventional to register static routes (like /search) before parameterized routes (like /:id) for better readability.

♻️ Suggested refactor

-	users := router.Group("/users")
-	users.GET("", getAllUsers)
-	users.POST("", createUser)
-	users.GET("/:id", getUserByID)
-	users.DELETE("/:id", deleteUser)
-	users.PUT("/:id", updateUser)
-	users.GET("/search", searchUsers)
+	userRoutes := router.Group("/users")
+	userRoutes.GET("", getAllUsers)
+	userRoutes.POST("", createUser)
+	userRoutes.GET("/search", searchUsers)
+	userRoutes.GET("/:id", getUserByID)
+	userRoutes.PUT("/:id", updateUser)
+	userRoutes.DELETE("/:id", deleteUser)

---

50-50: Remove stale TODO comment.

The handlers are implemented, so this TODO is no longer applicable.

🧹 Suggested removal

-// TODO: Implement handler functions
-
 // getAllUsers handles GET /users

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Age cannot be set to zero with current partial update logic.

The check input.Age != 0 means if a client sends {"age": 0}, the update is ignored. While age=0 is unlikely in practice, this is a limitation of using zero-values for partial updates. A common pattern is to use pointer fields (*int) or a separate struct with omitempty handling to distinguish "not provided" from "explicitly set to zero."

For this challenge, this is likely acceptable, but worth noting.

🤖 Prompt for AI Agents

In `@packages/gin/challenge-1-basic-routing/submissions/Mxn-ptr/solution.go`
around lines 156 - 164, The partial-update logic uses the zero value check
input.Age != 0 so an explicit {"age":0} is ignored; change the input DTO to make
Age a pointer (e.g., *int) and update the handler to check input.Age != nil and
then set user.Age = *input.Age (leave Name/Email checks as-is), and ensure the
JSON binding tags on the input struct allow distinguishing omitted vs provided
fields.