Can someone suggest me some good sources of routing with go ? i dont want to touch gorilla/mux

i want to learn routing in go (no 3rd party library) , i believe i should know to do it with go and also i dont want to depend on 3rd party library (to the maximum extent possible ), not saying that gorilla/mux is bad but i really don’t like using 3rd party library unless i dont have a choice (like open GL , open SSL)

1 Like

Well, then net/http is your tool. Specifically, the ServeMux for routing: https://golang.org/pkg/net/http/#ServeMux

2 Likes

Well, is not a very good idea to avoid using a router like gorilla/mux. The project is very mature and well maintained. Also is used in hundred of projects. Of course you can write all from scratch but i guess is long way until you will implement all those matches, midleware and so on.
If you are afraid of surprises (like incompatibilities, or worse… abandon) you can use vendor folder to download,use and redistribute (see license) a fixed version of mux with your project.

1 Like

As a counter point, I’ve done lots of web services using just net/http. The Gorilla mux has it’s place and it’s nice to have once you start juggling lots of placeholders in the endpoint paths and whatnot. But it’s totally valid to start with net/http until you reach a point where you think that’s cumbersome for whatever reason, and then you have a good base for the decision to switch to something more complex.

5 Likes

Have you seen https://github.com/quii/learn-go-with-tests ?

Specifically the HTTP Server and JSON, routing and embedding sections. Those sections show how to begin building a simple server with net/http. Parsing request.URL.Path for variables, method matching, etc…

I believe further along the writer ends up switching to gorilla/mux. That process may be interesting to see.

2 Likes

I like this approach:

https://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html

For another example, see:

1 Like

Let me being the devil’s lawyer for a while for the sake of a constructive debate :hugs:

I’m agree with using standard library for small things, learning or contrariwise many isolated services. Though, for the others, a router (here we talked about gorilla) is a good idea for confort, particularly gorilla make things very clear and readable.

An aproach like in the previous article mentioned by @Cliff_Brake, can be interesting by technique but i think that is not to practical from project management angle of view.
For example the author consider a framework a big load of code, also hard to debug. Well, the aport of code is very resonable considering the dimension of the executable. About debuging, you make this at your handler level not at router level, i don’t know, what do you expect to debug in the router?

Another point is the complexity of a code like this or the one from article. I saw a code unclear, hard to read, hard to understand, probably hard to extend and that’s not so good for a serious project and, if you want, not so idiomatic with the Go simplicity paradigm. Adding autentication or switching methods can conduct to a completly mess… I suggest this small example to see what i mean.

1 Like

@geosoft1 valid points – it is mostly a matter of preference and what is important to you. If reducing lines of code is important, then Gorilla:mux is good. If reducing coupling and flexibility is important, then implementing routes in handlers is a good way to go.

One additional benefit I’ve found in implementing routers in handlers is it helps you organize the routes as a clean route hierarchy emerges because you can’t just put in random paths – things need to fall through in a logical fashion.

I have not implemented authentication, etc yet using this method, so it is still experimental for me. But, authentication is typically implemented by wrapping handlers with middleware, so I’m not sure why this would be significantly different between the two methods.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.