TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: A sample project for Golang

57 点作者 shivylp超过 6 年前
I have been using golang at work and personally for more than 2 years now. A problem i faced when I started and the problem new gophers even today is how to structure the project. Most (if not all) golang tutorials seem to be very simple and do not describe how to structure a large application. Following project is an attempt to Showcase a manageable project layout for services in golang.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;spy16&#x2F;droplets" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;spy16&#x2F;droplets</a><p>This project is far from complete. Would like to hear some feedback from the community before continuing on this.

7 条评论

divan超过 6 年前
I really appreciate the work done to help newcomers to answer the question &quot;how to structure Go project propertly&quot;, but unless you&#x27;re building N-th microservice in the company with already established project structures, you don&#x27;t really need to ask that question.<p>Every single Go program starts with a simple layout - empty directory and main.go file.<p>Once you start adding things, you create more .go files in the same folder, and only when it grows bigger you start thinking of moving some abstractions into separate packages.<p>The key difference with most other languages is that in Go folder means &quot;package&quot;, not &quot;namespace for bunch or files&quot;. It&#x27;s a crucial difference that important to keep in mind with Go. And what is (sub)package? When do you need new subpackage? It&#x27;s just a higher level way to abstract logic or system component - make it more isolated than just concrete type, change the naming and usage API to be more clear and self-sustained.<p>Before that, you don&#x27;t have to create new packages (=folders) in Go.<p>The vast majority of all Go projects will never need `internal` or `cmd` folder, not to mention `pkg` or `web`.<p>Just start with main.go and let it grow naturally. The simpler and easier your package is, the better.
评论 #18551625 未加载
评论 #18558270 未加载
评论 #18551614 未加载
评论 #18560360 未加载
gtrubetskoy超过 6 年前
You might like to read my BP from 2017: <a href="https:&#x2F;&#x2F;grisha.org&#x2F;blog&#x2F;2017&#x2F;04&#x2F;27&#x2F;simplistic-go-web-app-part-2&#x2F;" rel="nofollow">https:&#x2F;&#x2F;grisha.org&#x2F;blog&#x2F;2017&#x2F;04&#x2F;27&#x2F;simplistic-go-web-app-par...</a> I have been using this layout in many projects and it worked out really well. When having multiple packages under the same github repo, you sooner or later will run into the problem of what happens if it&#x27;s forked, I have work-around here: <a href="https:&#x2F;&#x2F;grisha.org&#x2F;blog&#x2F;2018&#x2F;10&#x2F;18&#x2F;relative-imports-hack-in-go&#x2F;" rel="nofollow">https:&#x2F;&#x2F;grisha.org&#x2F;blog&#x2F;2018&#x2F;10&#x2F;18&#x2F;relative-imports-hack-in-...</a>
tuyguntn超过 6 年前
Thanks for the work done.<p>Current project structure felt like non-Go way to me, let me explain why, I always thought go packages should be independent (not sure about sub-packages though)<p>`encoding&#x2F;json`, `encoding&#x2F;gob` they do share concept of encoding&#x2F;decoding, but contain totally different implementations, types, models, logic inside. whenever you change something in `encoding&#x2F;gob` package, you don&#x27;t need to touch `encoding&#x2F;json`<p>but in proposed structure. whenever you want to add some logic, you would end up adding stuff in multiple places, starting with `domain`, then `stores`, then `delivery` (but this is exception, since this would be changed anyway as this is view layer), then other places.<p>Wouldn&#x27;t it make sense if you update only specific package (except view layer)<p>let&#x27;s say, you have `user` package with all necessary models, storage, business logic related to user and dependency from `core&#x2F;db` package. Now you want to add avatar to user, change only in `user` package and that&#x27;s all.<p>same with auth mechanism, call your package as `auth` and have a dependency on `cookies`&#x2F;`session` and `user` package, if you want to add OAuth2 only change auth, no need to add yet another model to `domain`, want to add token based auth, again just change auth package set&#x2F;create necessary tokens on top of `session` package using `user.Entity` or `user.GetID(authedEntity)`
评论 #18558810 未加载
somada141超过 6 年前
I personally love the idea of template projects especially when they follow best practices. I’m a long-time user of <a href="https:&#x2F;&#x2F;github.com&#x2F;audreyr&#x2F;cookiecutter" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;audreyr&#x2F;cookiecutter</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;audreyr&#x2F;cookiecutter-pypackage" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;audreyr&#x2F;cookiecutter-pypackage</a> which I’ve modified for my purposes. Has anyone used the golang equivalent under <a href="https:&#x2F;&#x2F;github.com&#x2F;lacion&#x2F;cookiecutter-golang" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lacion&#x2F;cookiecutter-golang</a> ? Any thoughts as to whether it’s on par with commonly used practices?
mneves超过 6 年前
This is a useful repo for how to structure a Go project: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang-standards&#x2F;project-layout" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang-standards&#x2F;project-layout</a>
emourujarvi超过 6 年前
Thanks, I started learning golang few weeks ago, and had a problem with how to structure my code.
评论 #18551580 未加载
rsneha超过 6 年前
Nice work i really like it
评论 #18551555 未加载