Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A sample project for Golang

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 18 posts

Show HN: A sample project for Golang

#1

Post by shivylp »

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.

https://github.com/spy16/droplets

This project is far from complete. Would like to hear some feedback from the community before continuing on this.

Re: Show HN: A sample project for Golang

#3

Post by gtrubetskoy »

You might like to read my BP from 2017: https://grisha.org/blog/2017/04/27/simplistic-go-web-app-par... 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's forked, I have work-around here: https://grisha.org/blog/2018/10/18/relative-imports-hack-in-...

Re: Show HN: A sample project for Golang

#4

Post by divan »

I really appreciate the work done to help newcomers to answer the question "how to structure Go project propertly", but unless you're building N-th microservice in the company with already established project structures, you don't really need to ask that question.

Every single Go program starts with a simple layout - empty directory and main.go file.

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.

The key difference with most other languages is that in Go folder means "package", not "namespace for bunch or files". It's a crucial difference that important to keep in mind with Go. And what is (sub)package? When do you need new subpackage? It'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.

Before that, you don't have to create new packages (=folders) in Go.

The vast majority of all Go projects will never need `internal` or `cmd` folder, not to mention `pkg` or `web`.

Just start with main.go and let it grow naturally. The simpler and easier your package is, the better.

Re: Show HN: A sample project for Golang

#7

Post by shivylp »

emourujarvi wrote: post #2

Thanks, I started learning golang few weeks ago, and had a problem with how to structure my code.

Welcome to Golang!. I'm glad you found this useful. But i advise you to look at other patterns as well. This is just one of the patterns that can be used and may not be suitable for all usecases. For example, for smaller projects a much simpler layout with main or importable package at the root would work really well. Just to give an idea, my other project https://github.com/spy16/radium follows a very simple straightforward layout.

Re: Show HN: A sample project for Golang

#8

Post by emourujarvi »

divan wrote: post #4

I really appreciate the work done to help newcomers to answer the question "how to structure Go project propertly", but unless you're building N-th microservice in the company with already established project structures, you don't really need to ask that question. Every single Go program starts with a simple layout - empty directory and main.go file. Once you start adding things, you create more .go files in the same…

When using a single folder structure, how should one go about creating multiple functions with a same name?

I'm creating a web service with Gin, and I have moved each http request handler into its own file. I would like to be able to pass these request handlers to Gin's router with pageA.Handler, pageB.Handler, pageC.Handler, etc, but compiler won't let me because function names have to be unique. Creating unique names for each handler function works fine, but personally it somehow feels messy.

Am I thinking anti-golang way, if I want to namespace these request handlers?

Re: Show HN: A sample project for Golang

#9

Post by dullgiulio »

divan wrote: post #4

I really appreciate the work done to help newcomers to answer the question "how to structure Go project propertly", but unless you're building N-th microservice in the company with already established project structures, you don't really need to ask that question. Every single Go program starts with a simple layout - empty directory and main.go file. Once you start adding things, you create more .go files in the same…

Absolutely. And never group files in a package by type ("models".) A package should have a function ("auth", "health", "reporting", ...)

Re: Show HN: A sample project for Golang

#10

Post by dullgiulio »

emourujarvi wrote: post #8
divan wrote: post #4

I really appreciate the work done to help newcomers to answer the question "how to structure Go project propertly", but unless you're building N-th microservice in the company with already established project structures, you don't really need to ask that question. Every single Go program starts with a simple layout - empty directory and main.go file. Once you start adding things, you create more .go files in the same…

When using a single folder structure, how should one go about creating multiple functions with a same name? I'm creating a web service with Gin, and I have moved each http request handler into its own file. I would like to be able to pass these request handlers to Gin's router with pageA.Handler, pageB.Handler, pageC.Handler, etc, but compiler won't let me because function names have to be unique. Creating unique nam…

Sort of yes. I have never tried Gin and I actually suggest you to use something else, like gorilla/mux, but that said what you describe sounds like several types implementing an interface...
Post reply on HN