sponge VS golang-standards/project-layout

Install a scaffold named sponge (integrated with Gin + Gorm), which supports Windows, macOS, and Linux environments. Click to view the installation instructions for sponge.

Sponge can be installed on Windows, macOS, and Linux. Check the installation instructions for details.

Using the tool sponge, the business logic code and non-business logic code are automatically separated during the code generation process, so that the development only needs to focus on the business logic code.

With the help of a code generation tool, sponge, download here https://github.com/zhufuyi/sponge

Download Address：https://github.com/zhufuyi/sponge

Sponge is a quick creation of web services and microservice tools, but also a microservice framework, sponge has a wealth of generated code commands, commonly used repetitive code and scripts are automatically generated, coupled with code decoupling modular design, it is easy to build a complete code project from development to deployment, thereby improving development efficiency.

Dependency plugins and tools are automatically installed after executing the command: protoc-gen-go, protoc-gen-go-grpc, protoc-gen-validate, protoc-gen-gotag, protoc-gen-go-gin, protoc-gen-go-rpc-tmpl, protoc-gen-openapiv2, protoc-gen-doc, golangci-lint, swag, go-callvis.

sponge is a microservice framework, a tool for quickly creating microservice code. sponge has a rich generating code commands, a total of 12 different functional code, these functional code can be combined into a complete service (similar to artificially broken sponge cells can be automatically reorganized into a new sponge ). Microservice code features include logging, service registration and discovery, registry, rate limit, circuit breaker, trace, metrics monitoring, pprof performance analysis, statistics, caching, CICD. The code uses a decoupled layered structure and it's easy to add or replace functional code. As an efficiency-enhancing tool, commonly repeated code is basically generated automatically and only business logic code needs to be populated based on the generated template code examples.

cmd: here where we will leave the main.go that starts our app.

> https://github.com/golang-standards/project-layout

The name of the repo is really and intentionally misleading. rsc filled an issue there to point this out, but the repo maintainer just disabled issues altogether so now no one can see it.

Even when it would not have such parasitic name, many seasoned Go programmers, me included, consider the self-proclaimed "Standard Go project Layout" as the opposite of what is good and advisable.

Unfortunately, the name just works, so it is being recommended all over the Internet since its inception.

Your comment makes it look as if you're saying you hate the Go development team, but it seems that isn't the case.

I get a little of what you're saying, I wouldn't say I hate anyone, but I strongly dislike how a lot of projects are organized. I think a lot stems from https://github.com/golang-standards/project-layout , which pretended to be standard and was so (ab)used one of the creators opened an issue about it. If you look at the actual Go src, it's much, much cleaner.

So you don't get blind sided for self proclaimed "standards" that are not

I am writing a project that has two components: a CLI and a library. I've organised the project as follows (as per organisation instructions):

Familiarity with the standard Golang project structure, which you can find here.

I've been learning how to build web applications using different frameworks and languages for a while now, such as Laravel with its MVC architecture and Node.js following the 'Hapi.js Way'. As I'm trying to create a new portfolio project using Go, I found myself contemplating over the ideal project structure. I wanted something that not only aligns with the standard Go project layout, but also makes the code both easy to write and understand. That's when I stumbled upon the concept of Hexagonal Architecture, as showcased in Netflix's engineering blog. The idea of seamlessly swapping infrastructures with minimal code changes fascinated me, and I decided to implement it in my new project.