ozzo-validation VS mux

go-ozzo/ozzo-validation

https://github.com/go-ozzo/ozzo-validation Seems to do what I need but likely will need some convoluted reflection to build out the rules. Also likely some custom rules to be written which is okay since it's a one time cost and reuse in the expressions.

Personally I use ozzo validation: https://github.com/go-ozzo/ozzo-validation

This looks useful, but what differentiates it from something like https://github.com/go-ozzo/ozzo-validation ? Why would I use Valgo over something battle tested that follows a very similar pattern?

This is where it gets spicy: I just don't get at all who ever though this struct-tag based validation library was a good idea https://github.com/go-playground/validator - and yet it's the most mainstream one. Try to implement your own type, you're up to register some global validation tag and repeat it every time you're using that type. I'm grateful https://github.com/go-ozzo/ozzo-validation exists, that's what I use. But it's still way behind the other things I mention, where in general, it's simply not possible to pass around an invalid struct - because it can't be built if it's invalid in the first place.

Gin comes with built-in "validation", while Echo recommends the same validator. I am also not a fan of magic struct tags, so I would probably prefer either writing my own or using something like ozzo.

Other packages of note: https://github.com/uber-go/zap https://github.com/go-ozzo/ozzo-validation

Does https://github.com/go-ozzo/ozzo-validation meet your requirements?

https://github.com/go-ozzo/ozzo-validation/blob/v3.6.0/struct.go#L61

This is not a disproval, but gorilla/mux has comparatively poor benchmark results among popular (many stars) third-party HTTP routers. , used by many users.

This attention to detail also can mean that for key abstractions in a tool or framework, what concretely goes on doesn't go unexplained. For example, when I was learning Go for web development, my first stumbling block was understanding how interfaces worked, particularly http.Handler, which is key to doing web development with Go's powerful net/http package and the fits-like-a-glove package built on top of it, the Gorilla Mux router. My way of finding out how that worked, and seeing the elegance of that interface, was pretty unorthodox - I figured out how Handlers worked by looking directly at Go's source code (which also is a demonstration of Go's readability, if you're interested in joining the Gophers!). And coming out of that was my very first tech talk at in 2015, on learning Gorilla from its Node.js counterpart, Express.js!

In this ApiGateway implementation, we've employed the Gorilla Mux router for enhanced route handling. Let's break down the key components:

Now that we have set up the Go environment, we can start building our API. The first step is to choose a framework. There are several popular frameworks for building APIs in Go, such as Gorilla mux, Echo, and Gin. For this article, we'll use Gorilla mux.

Mir is a toolkit to develop RESTful API backend service like develop service of gRPC. It adapt some HTTP framework sush as Gin, Chi, Hertz, Echo, Iris, Fiber, Macaron, Mux, httprouter。

My personal favorite tools: - https://github.com/go-kit/ for building services (although it's not necessary a great tool for prototyping) - https://github.com/gorilla/mux router (although it's been recently deprecated, so I'm looking for a similar, maintained library) - https://entgo.io/ ORM - https://watermill.io/ for messaging

We will be using Gorilla Mux to create the APIs locally. Gorilla Mux implements a request router and dispatcher to match the incoming requests.