Gin Interview Questions

A curated set of Gin interview questions covering its trade-offs against the standard library, middleware behavior, and request validation.

Gin vs net/http#

Q: What are the trade-offs of choosing Gin over plain net/http? Gin adds a fast radix-tree router with path parameters and grouping, a structured middleware chain, and one-call JSON binding plus validation — all of which save real boilerplate on any API beyond a handful of endpoints. The trade-off is an extra dependency and a small amount of framework-specific API (gin.Context, binding tags) to learn, though since Gin wraps net/http directly rather than replacing it, that knowledge transfers cleanly in both directions.

Q: Is Gin faster than net/http? Gin's router itself is very fast (a radix-tree implementation), and its overhead over raw net/http is negligible in practice — for the vast majority of real APIs, the bottleneck is the database or downstream calls, not routing overhead, so "faster" isn't usually the deciding factor between the two.

Q: Can a Gin application be served by the standard library's http.Server? Yes. *gin.Engine implements http.Handler, so it can be passed anywhere a net/http handler is expected — including http.ListenAndServe(addr, engine) directly, instead of the r.Run() shorthand.

Middleware#

Q: In what order does Gin execute middleware registered with r.Use()? In registration order for the request-inbound phase (each calls c.Next() to hand off to the next one), then in reverse order for any code that runs after their c.Next() call on the way back out — the same "onion" model used by most HTTP middleware systems, including ASP.NET Core's.

Q: What's the difference between c.Next() and c.Abort()? c.Next() proceeds to the next handler in the chain and returns control afterward. c.Abort() stops the chain immediately so nothing further down the chain runs, but it's still the calling code's responsibility to return right after — Abort() doesn't stop the current function from continuing to execute past that call.

Binding & validation#

Q: How does Gin combine JSON decoding and validation into one step? c.ShouldBindJSON(&input) deserializes the request body into the target struct and, if that struct has binding tags (required, email, min, etc.), validates it against those tags using the integrated go-playground/validator library — both in one call, returning a single error if either step fails.

Q: What happens if ShouldBindJSON fails? It returns a non-nil error describing what failed (malformed JSON, or a specific validation tag that didn't pass) and leaves the target struct in a partially- or fully-zeroed state. The handler is responsible for checking that error and responding appropriately (typically 400 Bad Request with the error message) — Gin doesn't do this automatically.

Testing and production#

Q: How do you test a Gin handler without starting a real HTTP server? Build a request with httptest.NewRequest and a response recorder with httptest.NewRecorder, then call router.ServeHTTP(recorder, request) directly. Since *gin.Engine implements the standard http.Handler interface, this exercises exactly the same routing and handler code a real server would, with no network socket involved.

Q: Why does graceful shutdown matter for a Gin server running in production? Stopping the process outright (a raw SIGKILL, or os.Exit) drops any request currently in flight. Running Gin through an explicit http.Server and calling srv.Shutdown(ctx) on SIGINT/SIGTERM stops accepting new connections immediately but lets in-flight requests finish naturally up to a deadline — important during every rolling deploy or container restart.