Golang Microservices Full Course #03 - Clean Architecture — CRUD User

Summary

This video episode builds a Go microservice user CRUD module using Clean Architecture, implemented with the Gin HTTP framework (not Echo). The focus is on structuring the code into layers, wiring them together, and then implementing the Register, Get Profile, and Update Profile endpoints.

---

Clean Architecture structure (layered design)

The project is split into four main layers:

1. Handler layer (HTTP / Gin)

   • Receives incoming requests (JSON body / route params)
   • Validates basic request decoding
   • Calls service methods and returns HTTP responses

2. Service / Use-case layer

   • Business logic for:
     • Register user
     • Get user profile by ID
     • Update user profile
   • Uses repository methods for data access
   • Uses context propagation (ctx) so cancellations/timeouts can propagate down to DB operations

3. Repository layer

   • Implements DB access using SQL (database/sql)
   • Uses an interface (userRepository interface) for abstraction

4. Model layer

   • Defines domain entities and request DTOs

---

Domain model & request/DTOs

model.User fields (entity)

• ID (string)
• FullName (string)
• Email (string)
• PasswordHash (string)
• CreatedAt, UpdatedAt, DeletedAt (time.Time-based fields)

Soft delete behavior is implied via DeletedAt (queries filter deleted users).

Request structs (DTOs)

• CreateUserRequest

  • FullName, Email, Password
  • Password minimum constraint is noted in subtitles: “6 is enough”

• UpdateUserRequest

  • FullName
  • (Password hashing/update is explicitly postponed to later episodes)

---

Repository interface + SQL implementation

An interface is created in internal/user/repository:

• Create(ctx, user) error
• GetByID(ctx, id) (user, error)
• GetByEmail(ctx, email) (user, error)
• Update(ctx, user) error
  • Updates full name; password update is not fully covered yet

SQL queries / soft-delete rules

• Create: inserts into users (id, full_name, email, password_hash, ...)
• GetByID: selects user fields from users where:
  • id = ?
  • deleted_at IS NULL (soft delete filter)
• GetByEmail: similar lookup by email with soft delete filtering
• Update:
  • updates full_name
  • uses WHERE id = ? with context passed to query

---

Service layer logic

The service is created with dependency injection:

• NewUserService(repo userRepository)

It also introduces:

• UUID generation for new user IDs (google/uuid)

Register user flow (service)

1. Checks if email already exists:
   • calls repo.GetByEmail
   • if found, returns an error like: “email already registered”
2. Creates a new model.User with:
   • ID = uuid
   • FullName, Email
   • PasswordHash planned (password hashing is mentioned as to be handled later)
3. Calls repo.Create

Get profile flow

• Calls repo.GetByID(ctx, id)

Update profile flow

1. Retrieves the user first:
   • if not found, returns the error
2. Updates fields:
   • updates FullName
3. Calls repo.Update

Password update logic is mentioned as not yet covered and expected to be added later.

---

Gin handlers (HTTP endpoints)

Routes are set up in a Gin router group (v1, /users).

Handlers accept/return JSON:

• Decode JSON body using Gin (c.ShouldBindJSON(...) implied)
• Use c.JSON(status, payload) for responses

Implemented endpoints (inferred from subtitles):

1. POST /v1/users

   • Body: CreateUserRequest
   • Returns:
     • 201 Created on success
     • 409 Conflict if email already exists

2. GET /v1/users/:id

   • Returns:
     • 200 OK with user profile
     • 404 Not Found if user does not exist

3. PUT /v1/users/:id

   • Body: UpdateUserRequest
   • Returns:
     • 200 OK on success
     • 500 Internal Server Error on failure

---

DB connection and app wiring

The episode includes wiring in cmd/main.go (or similar):

• Initialize database connection (DB)
• Create repository, then service, then handler:
  • repo -> service -> handler -> router
• Start server and log that routing is registered.

A warning appears about Gin trusted proxies:

Mentioned as a security concern in production, but “fine to ignore” for local testing.

---

Testing & debugging notes (Postman/curl)

• Testing suggestion:

  • use curl first, then Postman later

• Issues encountered:

  • A validation / missing method compile error for repository interface implementation
    • fixed by adding missing methods like GetByID
    • ensuring the repository struct implements all interface methods
  • curl request error due to wrong endpoint usage/params
    • includes messages like:
      • “destination is not API user…”
      • “Expected seven destinations … query raw context forgotten…”
    • (tooling/ORM-like behavior implied)

• Final confirmation:

  • User registration works
  • Get profile works
  • Update full name works (example shows updated updated_at timestamp)

---

Key “TODO / future episodes” items explicitly mentioned

• Password hashing is not fully implemented yet
  • password currently stored plainly in the demo; hashing is planned
• Update password / password change logic is not covered yet in this episode

---

Main speakers / sources

• Speaker: Instructor (unidentified; subtitles only indicate dialogue like “Hello back again…”)
• Primary external technologies used:
  • Gin: github.com/gin-gonic/gin
  • UUID: github.com/google/uuid
  • Go database/sql for DB access
• Other named speakers or sources: not provided beyond subtitles.