From 1f34c69ec88d60c65f4c5772041c0263172bc224 Mon Sep 17 00:00:00 2001 From: Hau Nguyen Date: Sun, 31 Jul 2022 00:10:40 +0700 Subject: [PATCH] chore: refactor location handler --- docs/2022-07-10-bootstrap-go.html | 2 +- posts/2022-07-10-bootstrap-go.md | 9 ++++++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/2022-07-10-bootstrap-go.html b/docs/2022-07-10-bootstrap-go.html index 9a38ab8..d791a58 100644 --- a/docs/2022-07-10-bootstrap-go.html +++ b/docs/2022-07-10-bootstrap-go.html @@ -15,7 +15,7 @@ internal | | service.go | | repository.go | | models.go -

All business codes are inside internal.
Each business has a different directory business.

Inside each business, there are 2 handlers: http, grpc:

For each handler, there are usually 3 layers: handler, service, repository:

handler must exist inside grpc, http.
But service, models can exist directly inside of business if both grpc, http has same business/logic.

Do not repeat!

If we have too many services, some of the logic will be overlapped.

For example, service A and service B both need to make POST call API to service C.
If service A and service B both have libs to call service C to do that API, we need to move the libs to some common pkg libs.
So in the future, service D which needs to call C will not need to copy libs to handle service C api but only need to import from common pkg libs.

Another bad practice is adapter service.
No need to write a new service if what we need is just common pkg libs.

Taste on style guide

Use functional options, but don't overuse it!

For simple struct with 1 or 2 fields, no need to use functional options.

Example:

func main() {
+

All business codes are inside internal.
Each business has a different directory business.

Inside each business, there are 2 handlers: http, grpc:

For each handler, there are usually 3 layers: handler, service, repository:

Location:

Do not repeat!

If we have too many services, some of the logic will be overlapped.

For example, service A and service B both need to make POST call API to service C.
If service A and service B both have libs to call service C to do that API, we need to move the libs to some common pkg libs.
So in the future, service D which needs to call C will not need to copy libs to handle service C api but only need to import from common pkg libs.

Another bad practice is adapter service.
No need to write a new service if what we need is just common pkg libs.

Taste on style guide

Use functional options, but don't overuse it!

For simple struct with 1 or 2 fields, no need to use functional options.

Example:

func main() {
 	s := NewS(WithA(1), WithB("b"))
 	fmt.Printf("%+v\n", s)
 }
diff --git a/posts/2022-07-10-bootstrap-go.md b/posts/2022-07-10-bootstrap-go.md
index 121d33b..b73a9e7 100644
--- a/posts/2022-07-10-bootstrap-go.md
+++ b/posts/2022-07-10-bootstrap-go.md
@@ -40,11 +40,14 @@ For each handler, there are usually 3 layers: `handler`, `service`, `repository`
 
 - `handler` interacts directly with gRPC, REST or consumer using specific codes (cookies, ...) In case gRPC, there are frameworks outside handle for us so we can write business/logic codes here too. But remember, gRPC only.
 - `service` is where we write business/logic codes, and only business/logic codes is written here.
-- `repository` is where we write codes which interacts with database/cache like MySQL, Redis, ... And we should place it directly inside of `business`.
+- `repository` is where we write codes which interacts with database/cache like MySQL, Redis, ...
 - `models` is where we put all request, response, data models.
 
-`handler` must exist inside `grpc`, `http`.
-But `service`, `models` can exist directly inside of `business` if both `grpc`, `http` has same business/logic.
+Location:
+
+- `handler` must exist inside `grpc`, `http`, `consumer`.
+- `service`, `models` can exist directly inside of `business` if both `grpc`, `http`, `consumer` has same business/logic.
+- `repository` should be placed directly inside of `business`.
 
 ## Do not repeat!