app-structure-examples - GitLite

KO | EN

gitlite — search

#javascript #llm #golang #android #machine-learning #deep-learning #linux #windows #cli #kubernetes #awesome-list #vue #mcp #openai

app-structure-examples

(★ 105)

Demonstrating various ways of structuring Go apps with some commentary

파일 탐색기

최종 버전 다운로드 (.zip)

- main.go
- README.md
- calorie_calculator.go
- input_parser.go
- main.go
- README.md
- - calories_by_elf_list.go
- input_parser.go
- main.go
- README.md
- - input_parser.go
  - input_parser_test.go
- - calories.go
  - elf.go
  - elves_list.go
  - elves_list_test.go
- main.go
- README.md
.gitignore
go.mod
go.sum
LICENSE
puzzle_input
README.md

# 설치 가이드

1. 코드 내려받기

git clone https://github.com/katzien/app-structure-examples

깃허브에서 프로젝트 코드 전체를 내 컴퓨터로 내려받습니다.

cd app-structure-examples

방금 내려받은 프로젝트 폴더 안으로 이동합니다.

2. Go

보통 추천

사전 준비물

Git GitHub에서 프로젝트 코드를 내려받으려면 필요합니다.
Go Go 언어 컴파일러 및 도구 모음입니다.

go build ./...

Go 프로그램을 컴파일해 실행 파일을 만듭니다.

go run .

따로 빌드하지 않고 바로 Go 프로그램을 실행합니다.

✅ 빌드가 에러 없이 끝나면 성공입니다. go run . 을 썼다면 터미널 출력을 확인하세요.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# All examples implement a solution to the Advent of Code 2022 Day 1 puzzle.

Here's the puzzle description (copied from [Advent of Code 2022](https://adventofcode.com/2022/day/1)):

--

The jungle must be too overgrown and difficult to navigate in vehicles or access from the air; the Elves' expedition traditionally goes on foot. As your boats approach land, the Elves begin taking inventory of their supplies. One important consideration is food - in particular, the number of Calories each Elf is carrying (your puzzle input).

The Elves take turns writing down the number of Calories contained by the various meals, snacks, rations, etc. that they've brought with them, one item per line. Each Elf separates their own inventory from the previous Elf's inventory (if any) by a blank line.

For example, suppose the Elves finish writing their items' Calories and end up with the following list:

```
1000
2000
3000

4000

5000
6000

7000
8000
9000

10000
```

This list represents the Calories of the food carried by five Elves:

- The first Elf is carrying food with 1000, 2000, and 3000 Calories, a total of 6000 Calories.
- The second Elf is carrying one food item with 4000 Calories.
- The third Elf is carrying food with 5000 and 6000 Calories, a total of 11000 Calories.
- The fourth Elf is carrying food with 7000, 8000, and 9000 Calories, a total of 24000 Calories.
- The fifth Elf is carrying one food item with 10000 Calories.

In case the Elves get hungry and need extra snacks, they need to know which Elf to ask: they'd like to know how many Calories are being carried by the Elf carrying the most Calories. In the example above, this is 24000 (carried by the fourth Elf).

Find the Elf carrying the most Calories. How many total Calories is that Elf carrying?

# FAQ
### Where would you put your Kubernetes manifests / Dockerfiles / database migrations / non-Go files?
I usually add them to the root directory of the project, or group them in a top-level directory. E.g.
```
├── main.go
├── README.md
├── .gitignore
├── config (e.g. database migration or schema files)
├── consumer (if event-driven)
├── dao
├── domain
├── handler
├── manifests
│ ...
```

### Do you use internal/external packages to indicate what's safe to import in other projects?
Not really. If anything I would only add an `external` directory to the root of my project for this purpose (everything else being internal by default). So not:
```
├── main.go
├── internal
│ ├── dao
│ ├── domain
│ ├── handler
│ └── service.go
├── external
│ └── types.go
```

But rather:
```
├── main.go
├── dao
├── domain
├── handler
└── service.go
├── external
│ └── types.go
```

I just like to keep things simple, and stick to at most one level of indentation. You lose that if your internal/external packages contain subdirectories.

I also don't really like the name `external`, because Go packages are typically "things" (not adjectives).

At work we actually use a `proto` package for this purpose. We use protobuf for microservice to microservice communication, and have an explicit rule that services can import only proto packages of other services (enforced by static analysis). This achieves the intent behind internal/external, but conveys a bit more meaning - `proto` contains protobuf definitions and constants which other services can use to interact with that service.

### Do you use cmd / pkg directories? 
No, and this is something I used to advocate in my talks on structuring Go apps!

I don't use these by default anymore. I realised they make the structure more complicated without bringing much benefit, unless I needed to have multiple main.go files. But that isn't the case for me most of the time, so I prefer to have my main.go file directly at the root of the project.

Pkg adds another layer of indentation for the rest of the packages, and I prefer to have a flat structure as much as possible to keep things simple. It doesn't add much benefit unless you prefer to clearly separate your Go code from any other non-Go files or directories. I guess it might help if your project tree is huge, but I tend to use microservices so rarely run into this problem. ☺️