hi,
I understand what / why you came to that given your explanation,
but I disagrees a lot to it.
I don t feel like expanding code helps to better explain
the how/what/why of a sudden 42 question ? (why this /whatever/ has failed,
I believe it should not)
I m pretty sure its a good way to multiply keystrokes, and harden
maintenance and changes.
In the example you taken, because its not representative of all 42
questions** (only few ones),
the solution is to provide a more speaky app.
In your post you take that route example,
"/articles/{category}/{id:[0-9]+}"
And later expand and rewrite it to return a proper error when an id is not
an int,
Behavior that is totally excluded at the moment you decided
to apply a pattern on your route.
You are comparing things that are not comparable,
the route can be
"/articles/{category}/{id}"
The gorilla handler can handle the type checking and return a proper error
code.
So, you can resolve the 42 question,
not by diving in the code,
but by reading the error messages,
or *reading at the documentation.*
(note: reading the error messages=> totally fail when you develop a
website, not an api, as the error page is often generic and do not provide
a deep explanation of the error, as the end user does not care about it,
sometimes you can trick about it (put that in some comments/whatever/) but
any serious security test team will warn you about it)
Or that /foo/123 is, technically, an illegal argument, not a missing page.
I couldn't really find a good answer to any of these questions in the
documentation of gorilla/mux for what it's worth. Which meant that when my
web app suddenly didn't route requests correctly, I was stumped and needed
to dive into code.
None of the solution compared here, ie gorilla vs plain code, manages
correctly this feature.
In both case its an additional job to be done, in one way or another.
Somewhere you also talk about the idea that using a router would tightly
link
components by their types, adn that is bad in your opinion.
In my opinion, I m very happy about tight types coupling.
Like very very very very very very very happy about that.
Its the only thing i can rely on
to apply an understanding and validates that things gonna work
without being able to provide a formal proof (if i could, tbh).
*Type* here can be an interface or a value, that does not matter, their
guarantees matter.
Something i truly agree with you,
They only need to know about the immediate handlers they delegate to and
they only need to know about the sub-path they are rooted at
Local problem solving is always way easier to handle
than large scaled problems across files/packages/concepts.
In that regard i do agree with you about the last proposal you give in its
intentions,
I clearly disagree in its implementation,
it just not gonna work for me to write that much of code to solve those
problems.
** the other kind of 42 questions is about functions that behaves
differently from what the user expects.
Which happens in few cases, wrong documentation from author, misreading
from consumer, and at least that third one, a name which is both too vague
and too precise to give sufficient meaning about its purposes by itself,
example
/whatever/.Each() /whatever/ {...}
You can t tell what s going to happen in Each (will that call allocate?)
without knowing what is /whatever/,
if whatever is an array, you can *deduce* there will be an allocation,
if its something else like a stream, you can *deduce* it won t.
Because the name is not sufficient to describe its meaning on a so vague /
general context,
the problems takes scale, thus have an air of mystery.
That happens only with some kind of names,
as soon as you enter a specific context (what mean to Put to a dht table
?),
you gonna need to learn the specifics of the problem before,
by definition the local question is scaled to the context of your general
situation (something like this),
naturally its has an air of mystery,
naturally you need to learn and assert about the details (via the code or
the doc).
_________________
about the question, why there s so much alternative routers.
My personal opinion, gorilla mux is great, but its an enter step for many
people,
so they need to learn both the language + the framework + quickly they need
to assimilate
some pretty fine tune trick of the language to keep going,
and so it become difficult, and so alternatives has a reason to happen.
Also some constructs, while being very verbose, are not obvious...
http.Handle("/static/", http.StripPrefix("/static/",
http.FileServer(http.Dir("./public"))))
Super verbose.
So clear that we need stackoverflow to make it happen the first time.
Another possible reason, as all in things in golang,
it has to be verbose,
we ain t all like that,
easy path for a developer to think that i can fix that.
And no, i m not saying verbosity is bad,
i m saying that verbosity is not affordable,
it is super expensive when most of the code produced out there is trash
code,
or consumable code if you prefer to be more politically correct.
When a project succeed
the code is created, consumed/maintained for a while,
then replaced.
Put simply we don t all work on a programming language
that s going to live for decades (its the best i hope for golang).
If i d try to resume that in one (or two) statement(s),
verbosity is not simplicity ... simplicity is complex.
So, how to solve the epidemic ?
IF you could, that is by providing a package that answers all POV with 100%
matching,
but you can t really,
at best you can only provide a choice that is favorable to the re use Vs re
create most of the time,
at the end, its always the user that balances the benefits and the costs
from his POV,
*assuming* he passed the technical barrier.
Last dump:
https://fr.wiktionary.org/wiki/l%E2%80%99enfer_est_pav%C3%A9_de_bonnes_intentions
On Monday, June 19, 2017 at 12:02:37 AM UTC+2, Axel Wagner wrote:
>
> Hey gophers,
>
> in an attempt to rein in the HTTP router epidemic, I tried writing down a)
> why I think *any* router/muxer might not be a good thing to use (much
> less write) and b) what I consider good, practical advice on how to route
> requests instead. It's not rocket science or especially novel, but I wanted
> to provide more useful advice than just saying "just use net/http" and
> haven't seen that a lot previously.
>
> Feedback is welcome :)
> http://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
