Backend chưa có Frontend (hoặc UI/UX Design) thì hình dung API & thiết kế Database thế nào?

Một trong những tình huống khó chịu nhất của backend dev: Frontend chưa làm, UI chưa có, nhưng deadline backend vẫn tới gần.

Làm sao để thiết kế API và database mà không cần “đoán mò”?

1. Vấn đề: Backend mà chưa có UI thì “thiếu context”

Thông thường, UI/UX là nguồn gốc của mọi luồng dữ liệu.

Khi bạn nhìn thấy form đăng ký, bạn biết ngay mình cần những trường gì: name, email, password, v.v.

Khi có dashboard, bạn biết hệ thống cần lọc, phân trang, thống kê như thế nào.

Nhưng nếu frontend chưa có, backend rơi vào thế mù thông tin:

• Không biết người dùng sẽ nhập những gì.

• Không rõ dữ liệu nào là bắt buộc.

• Không biết mối quan hệ thực tế giữa các thực thể trong hệ thống (user – order – payment…).

Nếu bạn cố “đoán” và làm luôn, rất dễ rơi vào 2 hậu quả:

1. Database sai hướng, sau phải migrate hoặc refactor cực kỳ tốn công.

2. API không khớp thực tế, frontend build xong lại phải sửa toàn bộ contract.

2. Nguyên tắc vàng: “Thiết kế API dựa trên use case, không dựa trên UI”

UI chỉ là phần trình bày.

Thứ bạn thật sự cần hiểu là business flow (luồng nghiệp vụ).

Ngay cả khi chưa có UI, bạn vẫn có thể dựng được API chuẩn nếu nắm được:

• Người dùng (actor) là ai.

• Họ cần làm gì (use case).

• Kết quả cuối cùng là gì (outcome).

Ví dụ, bạn đang làm hệ thống e-learning.

Không cần UI, bạn vẫn có thể viết ra các use case:

Từ bảng này, bạn đã có thể nhìn ra các entity chính:

User, Course, Enrollment, Lesson, AdminApproval…

=> Và từ đó bắt đầu thiết kế Database & API mà không cần chờ UI.

3. Quy trình cụ thể để backend chủ động khi chưa có UI

Bước 1. Viết lại user stories theo kiểu “As a … I want to … so that …”

Ví dụ:

• As a student, I want to enroll in a course so that I can access lessons.

• As a teacher, I want to upload video lessons so that students can learn.

Từ đây, bạn có thể nhóm các story thành module backend.

Bước 2. Vẽ sơ đồ thực thể (ERD) từ user stories

Dựa trên luồng hành động, bạn liệt kê các entity và mối quan hệ.

Ví dụ (với e-learning):

User (1) --- (n) Enrollment (n) --- (1) Course
Course (1) --- (n) Lesson

Dù chưa có UI, bạn vẫn có thể biết được các quan hệ logic để tạo database sơ bộ.

Bước 3. Dựng API Contract bằng OpenAPI (Swagger)

Khi chưa có frontend, API spec chính là bản thiết kế trung gian giữa backend và UI.

Bạn có thể viết file openapi.yaml với các endpoint giả định:

paths:
  /courses:
    get:
      summary: Get all courses
      responses:
        200:
          description: List of courses

Sau đó, frontend (khi có) có thể tự mock hoặc generate code dựa vào swagger này.

=> Giúp hai bên làm song song mà không cần phụ thuộc.

Bước 4. Tạo mock UI hoặc mock API

Nếu muốn đi xa hơn, bạn có thể:

• Dùng Postman Mock Server, Mockoon, hoặc Stoplight để dựng fake API.

• Hoặc ngược lại: dùng Figma, Whimsical, Balsamiq để phác sơ UI, giúp xác thực logic dữ liệu.

4. Cách xác định cấu trúc database khi không có thiết kế UI

Tập trung vào domain model

Hãy mô hình hóa hệ thống như một domain thực tế, không phải theo form UI.

Ví dụ:

• UI có thể có 1 form “Tạo bài giảng”.

  Nhưng domain thực tế có thể là: Course → Section → Lesson → Content.

• Bạn không cần biết UI chia tab thế nào, chỉ cần hiểu quan hệ dữ liệu ra sao.

Ưu tiên quan hệ logic, không phải hiển thị

Đừng thiết kế DB theo kiểu “mỗi màn hình một bảng”.

Ví dụ: nếu bạn có UI “User Profile” và “User Settings”, đừng tách bảng nếu hai thứ thuộc cùng entity.

Dự đoán “data flow”

Ngay cả khi không có UI, bạn vẫn có thể viết sơ đồ tuần tự (sequence diagram) để mô tả:

• Ai gọi API nào

• API đó trả gì

• Dữ liệu đi qua các tầng nào (controller → service → repo)

5. Khi không có UI, hãy làm việc như một API Product Designer

Hãy xem API là sản phẩm mà frontend là khách hàng.

“Nếu frontend chưa có, hãy giả vờ chính bạn là người viết frontend.”

Cách làm:

• Tự viết các test call đến API (dùng Postman hoặc cURL).

• Giả lập các scenario thực tế (tạo user, đăng nhập, enroll, thanh toán…).

• Kiểm tra xem dữ liệu trả về đã dễ dùng cho frontend chưa.

Nếu bạn làm tốt phần này, khi frontend vào sau sẽ cực kỳ thuận lợi:

• Không cần đổi field name.

• Không cần đổi response structure.

• Không cần thêm query tùy chỉnh.

6. Dùng “Contract-first” để làm song song với frontend

Kỹ thuật này rất phổ biến trong các team chuyên nghiệp.

Ý tưởng:

• Bạn viết API spec trước (bằng OpenAPI, Swagger, hoặc Postman Collection).

• Sau đó backend và frontend cùng dựa trên contract này để phát triển song song.

• Backend tạo mock response.

• Frontend gọi API mock để build UI trước.

Công cụ đề xuất:

• Swagger Editor / Stoplight: Viết và preview OpenAPI file dễ dàng.

• Prism (by Stoplight): Tạo mock server từ OpenAPI.

• Postman Mock Server: Cho phép chia sẻ endpoint thật giữa team.

7. Khi nào nên delay việc thiết kế DB?

Nếu bạn nhận thấy:

• Business chưa rõ ràng.

• Requirement còn mơ hồ (chưa có flow cụ thể).

• Các entity có thể thay đổi lớn trong thời gian ngắn.

Hãy chỉ dựng sơ đồ logic (conceptual model) chứ chưa tạo DB thật.

Ví dụ:

User
Course
Enrollment
Payment

Sau khi có UI hoặc flow chính xác, bạn mới chốt field và constraint chi tiết.

8. Case study: Team backend làm trước, frontend sau

Giả sử bạn làm cho startup e-learning.

Giai đoạn 1: Chưa có UI

→ Bạn tạo các use case + OpenAPI contract

→ Dựng mock API với Swagger + Mockoon.

Giai đoạn 2: Backend dev

→ Bạn implement API thực tế dựa trên spec đó.

→ Test bằng Postman Collection.

Giai đoạn 3: Frontend bắt đầu

→ Họ dùng cùng spec để generate axios client.

→ Gọi mock API → sau đó thay baseURL bằng API thật.

Kết quả: hai team phát triển song song, không bị chờ nhau.

9. Checklist cho backend khi chưa có frontend

10. Kết luận

“UI là phần nhìn, API là phần nói — nhưng nếu hiểu được câu chuyện, bạn vẫn có thể nói trước khi thấy.”

Là backend dev, bạn không cần chờ UI mới bắt đầu được.

Điều quan trọng là bạn phải hiểu rõ domain, use case và luồng nghiệp vụ.

Khi đó, API bạn thiết kế sẽ không chỉ đúng kỹ thuật, mà còn phản ánh đúng giá trị sản phẩm.

Một số công cụ giúp backend “tự hình dung UI”

• Whimsical — vẽ flow & sơ đồ nhanh

• Stoplight Studio — viết OpenAPI dễ như Notion

• Mockoon — tạo mock API offline

• dbdiagram.io — vẽ ERD nhanh gọn

Còn khi UI/UX đến sau — họ sẽ cảm ơn bạn vì mọi thứ đã sẵn sàng.