<p>So a week ago I posted about making a basic JSON API in Go.</p>
<p>What would you like to see next explained in a (hopefully) easy-to-consume tutorial?</p>
<hr/>**评论：**<br/><br/>dazzford: <pre><p>The more dependencies you have, the more a new person to the project has to learn. </p>
<p>As others mentioned node has this problem but so does java. To do real service development most people have to also know spring boot, plus IOC, often hibernate, and other libraries.</p>
<p>Cognitive load is a real thing and it slows down development.</p>
<p>This all said, everything is a tool; from language to pattern, to library. Use the right tool for the job. But to do that you need to know your options.</p></pre>PragmaCoders: <pre><p>Great discussion - Will definitely keep this all in mind!</p>
<p>I'll link to the article for the sake of context:</p>
<p><a href="https://pragmacoders.com/building-a-json-api-in-golang/" rel="nofollow">https://pragmacoders.com/building-a-json-api-in-golang/</a></p>
<p>I think there's also something to be said for the utility of teaching newcomers how to install dependencies. If I removed 'gorilla/mux' from that tutorial, suddenly there's no good way to explain how to use 'dep' and there'd have to be a bigger chunk of the tutorial dedicated to regular expressions (a notoriously ugly and hard to explain, if extremely useful and versatile tool) to accomplish the same goal.</p>
<p>It's not necessarily what I want the reader to come away remembering. Even if it's useful in a different way. </p>
<p>I can see the other side of it - Modern frontend JS tutorials might start the tutorial by having the reader install 10 libraries and build tools. They then have to make a choice to take a detour and explain them or to skip the explanation and get back to the task at hand. Can easily be overwhelming to the reader and put them in a niche of tools not optimal for them (without them knowing it).</p>
<p>I think in the context of that previous tutorial, I'm OK with the choice I made. Though I could potentially create or link to an article with more detail on how to use stdlib instead of the extra dependency. To give the reader the option to dig into the alternatives.</p>
<p>Good discussion, and I'll definitely keep it in mind, the desire to use stdlib unless there's a clear reason not to, for future tutorials!</p>
<p>Now is there anything you'd like to see built and explained, beginner-to-intermediate-level with a dependency tree of appropriate size for the problem? ;)</p></pre>dazzford: <pre><p>There are too many tutorials using external dependencies.
Your last post used gorillia mux. It's completely unnecessary; the std lib is more than capable and more important to learn.</p></pre>shovelpost: <pre><p>This might be an unpopular opinion but it carries wisdom. Think about it; if there are no tutorials showing how to do things without dependencies then the only way newcomers will ever know how to do things is by stringing together external packages.</p>
<p>What we need instead, ideally, is to keep the dependency tree at a minimum. So please write tutorials to showcase that.</p></pre>TheMerovius: <pre><blockquote>
<p>So please write tutorials to showcase that.</p>
</blockquote>
<p><a href="https://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html">shameless plug</a> :)</p></pre>ksirutas: <pre><p>I agree about people using too many dependencies, but gorilla/mux is a tried and true router. You can try creating one yourself, but unless you have a solid grasp on regexp, it’ll be harder for a beginner to create a watertight router. Imo.</p></pre>dazzford: <pre><p>Tried and true it not; it’s not necessary in most services, especially well constructed 12-factor pattern small services.</p>
<p>I have built and deployed dozens of go services into production in multiple companies even when needing dynamic properties in routes, it’s simple enough to slice up the string and get what you need out of it, all with the std lib.</p></pre>robe_and_wizard_hat: <pre><p>I don't doubt the stdlib is good at doing a lot of things, but it doesn't shine in the router category. Why not use a lib which makes things easier, is used everywhere, and homogenizes how you route requests across all of your APIs? I'd be really surprised to see anything beyond the most trivial API be routed natively just using the stdlib.</p></pre>titpetric: <pre><blockquote>
<p>Why not use a lib which makes things easier, is used everywhere, and homogenizes how you route requests across all of your APIs?</p>
</blockquote>
<ul>
<li>novices shouldn't build routers, they need to learn the stdlib and language features (that's why they read tutorials in the first place),</li>
<li>when they know how stdlib works, they know their <em>needs</em> and they can expand to use third party packages that satisfy them,</li>
<li>if you'd skip those things you might end up with the wrong choice, because you made that choice for <a href="https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/" rel="nofollow">all the wrong reasons</a>,</li>
<li>I'd argue that novices shouldn't have a need for homogenized API layer(s) yet, as they should still be learning what style works for them, and their projects actually should be those <em>trivial APIs</em> which you mention</li>
</ul>
<p>While it's easy to recommend <a href="https://github.com/go-chi/chi" rel="nofollow">go-chi/chi</a> for routing needs (it's really great imho), or gorilla/mux, or a significant number of other routing packages, you possibly making the novice skip of a very important question: "why would I use this router?" or "what problem am I trying to solve?". Part of the problem would be solved if some routing package would be considered as <em>official</em>, or at least close to something like that (see <code>dep</code> for an example).</p>
<p>I actually have a chapter of "choosing a router framework" in <a href="https://leanpub.com/api-foundations" rel="nofollow">API foundations</a> where I (as a novice would), made the mistake of choosing a routing framework, which had a significant pitfall. Ideally, I could have omitted that whole chapter, but I did want to show what happens when you're choosing software based on some external reference like curated lists or github stars. Unfortunately, this pitfall sometimes hits more experienced programmers as well.</p>
<p>So yeah, I agree with you, the stdlib doesn't shine in the router category, but if you're a novice, it (stdlib experience) should be a requirement, so the underlying principles are well understood. You don't need to write regexes or whatever, but you should know what limitations you're trying to overcome.</p></pre>UnscheduledArrival: <pre><p>What is with the Go community and it's hatred for external libraries?</p></pre>shovelpost: <pre><p>I wouldn't call it hatred. I'd say it is part of the Go philosophy which includes <a href="https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s">keeping the dependency tree at a minimum</a>.</p></pre>cascwo: <pre><p>Node ptsd</p></pre>
