update community-single

Author: zhufuyi

7_community-single/.golangci.yml

@@ -12,7 +12,6 @@ run:
   # default value is empty list, but default dirs are skipped independently
   # from this option's value (see skip-dirs-use-default).
   skip-dirs:
-    - pkg
     - docs
     - api
   # which files to skip: they will be analyzed, but issues from them
@@ -39,7 +38,7 @@ linters:
   # inverted configuration with `enable-all` and `disable` is not scalable during updates of golangci-lint
   disable-all: true
   enable:
-    - golint
+    - revive
     - goimports
     - gofmt
     - unused
@@ -66,6 +65,59 @@ linters:
 
 
 linters-settings:
+  revive:
+    rules:
+      - name: argument-limit
+        arguments: [ 8 ]
+      - name: atomic
+      - name: bare-return
+      - name: blank-imports
+      - name: bool-literal-in-expr
+      - name: call-to-gc
+      - name: confusing-naming
+      - name: confusing-results
+      - name: constant-logical-expr
+      - name: context-as-argument
+      - name: context-keys-type
+      - name: deep-exit
+      - name: defer
+      - name: dot-imports
+      - name: duplicated-imports
+      - name: early-return
+      - name: empty-block
+      #- name: empty-lines
+      - name: error-naming
+      - name: error-return
+      - name: error-strings
+      - name: errorf
+      - name: function-result-limit
+        arguments: [ 3 ]
+      - name: identical-branches
+      - name: if-return
+      - name: import-shadowing
+      - name: increment-decrement
+      - name: indent-error-flow
+      - name: modifies-parameter
+      - name: modifies-value-receiver
+      - name: package-comments
+      - name: range
+      - name: range-val-address
+      - name: range-val-in-closure
+      - name: receiver-naming
+      - name: redefines-builtin-id
+      - name: string-of-int
+      - name: struct-tag
+      - name: superfluous-else
+      - name: time-naming
+      - name: unconditional-recursion
+      - name: unexported-naming
+      - name: unnecessary-stmt
+      - name: unreachable-code
+      - name: unused-parameter
+      - name: var-declaration
+      - name: var-naming
+      - name: waitgroup-by-value
+
   dogsled:
     # checks assignments with too many blank identifiers; default is 2
     max-blank-identifiers: 2
@@ -126,10 +178,6 @@ linters-settings:
     # it's a comma-separated list of prefixes
     local-prefixes: community
 
-  golint:
-    # minimal confidence for issues, default is 0.8
-    min-confidence: 0.8
-
   gomnd:
     settings:
       mnd:

7_community-single/Makefile

@@ -3,24 +3,7 @@ SHELL := /bin/bash
 PROJECT_NAME := "community"
 PKG := "$(PROJECT_NAME)"
 PKG_LIST := $(shell go list ${PKG}/... | grep -v /vendor/ | grep -v /api/)
-#GO_FILES := $(shell find . -name '*.go' | grep -v /vendor/ | grep -v _test.go)
-
-
-.PHONY: install
-# installation of dependent tools
-install:
-	go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
-	go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
-	go install github.com/envoyproxy/protoc-gen-validate@latest
-	go install github.com/srikrsna/protoc-gen-gotag@latest
-	go install community/cmd/protoc-gen-go-gin@latest
-	go install community/cmd/protoc-gen-go-rpc-tmpl@latest
-	go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest
-	go install github.com/pseudomuto/protoc-gen-doc/cmd/protoc-gen-doc@latest
-	go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest
-	go install github.com/swaggo/swag/cmd/swag@latest
-	go install github.com/ofabry/go-callvis@latest
-	go install golang.org/x/pkgsite/cmd/pkgsite@latest
+
 
 
 .PHONY: mod
@@ -60,12 +43,6 @@ cover:
 	go tool cover -html=cover.out
 
 
-.PHONY: docs
-# generate swagger docs, the host address can be changed via parameters, e.g. make docs HOST=192.168.3.37
-docs: mod fmt
-	@bash scripts/swag-docs.sh $(HOST)
-
-
 .PHONY: graph
 # generate interactive visual function dependency graphs
 graph:
@@ -75,10 +52,16 @@ graph:
 	@rm -f main.go community.gv
 
 
+.PHONY: docs
+# generate swagger docs, only for ⓵ Web services created based on sql, the host address can be changed via parameters, e.g. make docs HOST=192.168.3.37
+docs: mod fmt
+	@bash scripts/swag-docs.sh $(HOST)
+
+
 .PHONY: proto
-# generate *.pb.go codes from *.proto files
+# generate *.go and template code by proto files, if you do not refer to the proto file, the default is all the proto files in the api directory. you can specify the proto file, multiple files are separated by commas, e.g. make proto FILES=api/user/v1/user.proto. only for ⓶ Microservices created based on sql, ⓷ Web services created based on protobuf, ⓸ Microservices created based on protobuf, ⓹ RPC gateway service created based on protobuf
 proto: mod fmt
-	@bash scripts/protoc.sh
+	@bash scripts/protoc.sh $(FILES)
 
 
 .PHONY: proto-doc
@@ -91,9 +74,7 @@ proto-doc:
 # build community for linux amd64 binary
 build:
 	@echo "building 'community', linux binary file will output to 'cmd/community'"
-	@cd cmd/community && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 GOPROXY=https://goproxy.cn,direct go build
-
-
+	@cd cmd/community && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build
 
 
 
@@ -109,12 +90,30 @@ run-nohup:
 	@bash scripts/run-nohup.sh $(CMD)
 
 
-.PHONY: docker-image
+.PHONY: binary-package
+# packaged binary files
+binary-package: build
+	@bash scripts/binary-package.sh
+
+
+.PHONY: deploy-binary
+# deploy binary to remote linux server, e.g. make deploy-binary USER=root PWD=123456 IP=192.168.1.10
+deploy-binary: binary-package
+	@expect scripts/deploy-binary.sh $(USER) $(PWD) $(IP)
+
+
+.PHONY: image-build-local
 # build image for local docker, tag=latest, use binary files to build
-docker-image: build
+image-build-local: build
 	@bash scripts/image-build-local.sh
 
 
+.PHONY: deploy-docker
+# deploy service to local docker, if you want to update the service, run the make deploy-docker command again.
+deploy-docker: image-build-local
+	@bash scripts/deploy-docker.sh
+
+
 .PHONY: image-build
 # build image for remote repositories, use binary files to build, e.g. make image-build REPO_HOST=addr TAG=latest
 image-build:
@@ -127,12 +126,6 @@ image-build2:
 	@bash scripts/image-build2.sh $(REPO_HOST) $(TAG)
 
 
-.PHONY: image-build-rpc-test
-# build rpc test image for remote repositories, e.g. make image-build-rpc-test REPO_HOST=addr TAG=latest
-image-build-rpc-test:
-	@bash scripts/image-rpc-test.sh $(REPO_HOST) $(TAG)
-
-
 .PHONY: image-push
 # push docker image to remote repositories, e.g. make image-push REPO_HOST=addr TAG=latest
 image-push:
@@ -145,22 +138,28 @@ deploy-k8s:
 	@bash scripts/deploy-k8s.sh
 
 
-.PHONY: deploy-docker
-# deploy service to local docker, you must first run 'make docker-image' to generate a docker image, if you want to stop the server, pass the parameter stop, e.g. make deploy-docker CMD=stop
-deploy-docker:
-	@bash scripts/deploy-docker.sh $(CMD)
+.PHONY: image-build-rpc-test
+# build rpc test image for remote repositories, e.g. make image-build-rpc-test REPO_HOST=addr TAG=latest
+image-build-rpc-test:
+	@bash scripts/image-rpc-test.sh $(REPO_HOST) $(TAG)
 
 
-.PHONY: binary-package
-# packaged binary files
-binary-package: build
-	@bash scripts/binary-package.sh
+.PHONY: patch
+# patch some dependent code, such as types.proto, mysql initialization code. e.g. make patch TYPE=types-pb , make patch TYPE=mysql-init
+patch:
+	@bash scripts/patch.sh $(TYPE)
 
 
-.PHONY: deploy-binary
-# deploy binary, e.g. make deploy-binary USER=root PWD=123456 IP=192.168.1.10
-deploy-binary: binary-package
-	@expect scripts/deploy-binary.sh $(USER) $(PWD) $(IP)
+.PHONY: copy-proto
+# copy proto file from the rpc server directory, multiple directories separated by commas. e.g. make copy-proto SERVER=yourServerDir
+copy-proto:
+	@sponge patch copy-proto --server-dir=$(SERVER)
+
+
+.PHONY: update-config
+# update internal/config code base on yaml file
+update-config:
+	@sponge config --server-dir=.
 
 
 .PHONY: clean
@@ -169,10 +168,10 @@ clean:
 	@rm -vrf cmd/community/community
 	@rm -vrf cover.out
 	@rm -vrf main.go community.gv
-	@rm -vrf internal/ecode/*go.gen.*
-	@rm -vrf internal/routers/*go.gen.*
-	@rm -vrf internal/handler/*go.gen.*
-	@rm -vrf internal/service/*go.gen.*
+	@rm -vrf internal/ecode/*.go.gen*
+	@rm -vrf internal/routers/*.go.gen*
+	@rm -vrf internal/handler/*.go.gen*
+	@rm -vrf internal/service/*.go.gen*
 	@rm -rf community-binary.tar.gz
 	@echo "clean finished"
 
@@ -184,7 +183,7 @@ help:
 	@echo ' make [target]'
 	@echo ''
 	@echo 'Targets:'
-	@awk '/^[a-zA-Z\-\_0-9]+:/ { \
+	@awk '/^[a-zA-Z\-_0-9]+:/ { \
 	helpMessage = match(lastLine, /^# (.*)/); \
 		if (helpMessage) { \
 			helpCommand = substr($$1, 0, index($$1, ":")-1); \

7_community-single/README.md

@@ -2,6 +2,10 @@
 
 <br>
 
+**Import [sql](https://github.com/zhufuyi/sponge_examples/blob/main/7_community-single/test/sql/community.sql) into mysql before you start.**
+
+<br>
+
 ### Community-single Introduction
 
 Community-single is a minimalist version of a community backend service that mainly includes user registration, login, follow-up and other functions, as well as the creation of content (text, images, videos), publishing, commenting, liking, and collecting. These functions are common in various community platforms, video platforms, live broadcast platforms and can be used as a reference for learning.
@@ -20,13 +24,12 @@ The development process relies on the sponge tool and requires sponge to be inst
 
 ### Generate project code
 
-After defining the data tables and API interfaces, generate web service project code based on the proto file in sponge's interface. Enter sponge's UI interface, click on the left menu bar 【protobuf】--> 【Web type】-->【Create web project】, fill in relevant parameters to generate web project code as shown below:
+After defining the data tables and API interfaces, generate web service project code based on the proto file in sponge's interface. Enter sponge's UI interface, click on the left menu bar 【Protobuf】→【Create web project】, fill in relevant parameters to generate web project code as shown below:
 
 ![community-single-web](https://raw.githubusercontent.com/zhufuyi/sponge_examples/main/assets/en_community-single-web.png)
 
 Unzip the code and change the folder name (e.g., community-single). A service only needs to generate code once. In this way, a basic framework for building a web service is completed with one click. Next, you can write business logic code within the web service framework.
 
-<br>
 <br>
 
 ### Writing Business Logic Code
@@ -65,7 +68,7 @@ The code generated by the `make proto` command is used to connect web framework
 
 The previously generated web service framework code and part of the business logic code generated according to the proto file do not include operations on MySQL tables. Therefore, it is necessary to generate dao (data access object) code according to MySQL tables. Dao code includes **CRUD** code for tables, cache code, and model code.
 
-Enter the sponge UI interface, click on 【Public】--> 【Generate dao CRUD code】 in the left menu bar, fill in relevant parameters to generate dao code, as shown below:
+Enter the sponge UI interface, click on 【Public】→ 【Generate dao CRUD code】 in the left menu bar, fill in relevant parameters to generate dao code, as shown below:
 
 ![community-single-dao](https://raw.githubusercontent.com/zhufuyi/sponge_examples/main/assets/en_community-single-dao.png)
 
@@ -75,16 +78,16 @@ There are three parts to specifying dao codes generated by MySQL tables.
 
 (1) **Generate model code**, in the `internal/model` directory, this is generated go structure code corresponding to gorm.
 
-(2) **Generate cache code**, in files under the `internal/cache` directory, during the process of writing business logic codes, caches may be used to improve performance. Sometimes default caches (CRUD) for tables cannot meet requirements and additional cache codes need to be added. Sponge supports one-click generation of cache codes. Click on 【Public】--> 【Generate cache codes】 in the left menu bar, fill in parameters to generate codes, then move the unzipped internal directory to community-single directory and directly call cache interfaces in business logic.
+(2) **Generate cache code**, in files under the `internal/cache` directory, during the process of writing business logic codes, caches may be used to improve performance. Sometimes default caches (CRUD) for tables cannot meet requirements and additional cache codes need to be added. Sponge supports one-click generation of cache codes. Click on 【Public】→ 【Generate cache codes】 in the left menu bar, fill in parameters to generate codes, then move the unzipped internal directory to community-single directory and directly call cache interfaces in business logic.
 
 (3) **Generate dao codes**, in files under `internal/dao` directory, during writing business logic codes, it will involve operating on MySQL tables. Sometimes default operations (CRUD) cannot meet requirements. At this time, custom functions and implementation codes for operating on MySQL tables need to be manually written. For example comment.go and post.go contain a small number of manually defined function methods for operating on msyql tables.
 
 <br>
 
 During development process sometimes MySQL tables will be modified or added. Codes generated based on MySQL tables need to be synchronized into project codes and handled in two situations:
 
-- After modifying MySQL table update codes: Just generate new model codes based on modified table and replace old model codes. Click on 【Public】--> 【Generate model codes】 in left menu bar, fill in parameters, select changed mysql table then move unzipped internal directory to community-single directory and confirm replacement.
-- After adding new mysql table: Just generate new dao codes based on added table and add them into project directory. Click on 【Public】--> 【Generate dao codes】 in left menu bar, fill in parameters, select added mysql table then move unzipped internal directory into community-single directory.
+- After modifying MySQL table update codes: Just generate new model codes based on modified table and replace old model codes. Click on 【Public】→ 【Generate model codes】 in left menu bar, fill in parameters, select changed mysql table then move unzipped internal directory to community-single directory and confirm replacement.
+- After adding new mysql table: Just generate new dao codes based on added table and add them into project directory. Click on 【Public】→ 【Generate dao codes】 in left menu bar, fill in parameters, select added mysql table then move unzipped internal directory into community-single directory.
 
 <br>
 <br>
@@ -343,4 +346,4 @@ This is a practical project using sponge from development to deployment. The spe
 
 It seems that there are many processes, but only 1, 2, 6 are three core business processes that require manual coding. The code or scripts involved in other processes are generated by sponge. Using sponge to separate non-business logic code from business logic code allows developers to focus on core business logic code when developing projects while also making project code standardized and uniform so that different programmers can quickly get started. Combined with programming assistance tools such as Copilot or Codeium to write code, project development becomes more efficient and easy.
 
-community-single is a monolithic web service. As the demand increases and the functionality becomes more and more complex, code maintenance and development become difficult. It can be split into multiple microservices. The process of splitting a web monolithic service into microservices only changes the eggshell (web framework changed to gRPC framework) and albumen (http handler-related code changed to rpc service-related code), while the yolk (core business logic code) remains unchanged. The core business logic code can be seamlessly ported to microservice code.
+community-single is a monolithic web service. As the demand increases and the functionality becomes more and more complex, code maintenance and development become difficult. It can be split into multiple microservices. The process of splitting a web monolithic service into microservices only changes the eggshell (web framework changed to grpc framework) and albumen (http handler-related code changed to grpc service-related code), while the yolk (core business logic code) remains unchanged. The core business logic code can be seamlessly ported to microservice code.