Sir Linus Torvalds có câu nói kinh điển "Talk is cheap, show me the code", thì trong bối cảnh phát triển sản phẩm hiện đại, tôi muốn mở rộng quan điểm đó thành: "Show me the number".

Và điều này không chỉ dành riêng cho Backend hay Frontend.


Anh em làm Product chắc không lạ gì kịch bản "tam sao thất bản" này:

  1. User: "Web chậm như rùa!" 🐢
  2. Backend: (Check Grafana) "Oan quá! API response time p99 có 50ms thôi. Server chạy vèo vèo mà?"
  3. Frontend: "Máy em load mượt mà, chắc do mạng user yếu."

Kết quả? User vẫn bỏ đi, còn team thì đổ lỗi cho nhau.

Vấn đề nằm ở đâu? Nó nằm ở "Điểm mù" (Blind Spot) giữa Server và Browser.

Để thực sự làm chủ sản phẩm, tư duy Data Driven phải được áp dụng End-to-End. Một request nhanh ở Backend không có nghĩa là User thấy nhanh ở Frontend.


1. Backend: Sự ổn định của hạ tầng (The Foundation)

Chúng ta vẫn giữ vững 3 trụ cột (Observability) để đảm bảo "nhà máy" vận hành tốt:

  • Metrics: Đo lường sức khỏe (RPS, CPU, Memory). Quan trọng nhất là Latency p95/p99 (để biết 5% user xui xẻo nhất đang chịu đựng điều gì).
  • Logs & Traces: Để truy vết lỗi và điểm nghẽn trong các Microservices.
  • Tools: Prometheus, Grafana, OpenTelemetry, ELK.


2. Frontend: Trải nghiệm thực tế (The Real User Experience)

Frontend không chỉ là vẽ UI, Frontend là nơi trực tiếp "hứng" cảm xúc của người dùng. "Cảm giác" chậm của User cần được lượng hóa bằng RUM (Real User Monitoring):



Tại đây, chúng ta không đo CPU Server, chúng ta đo Core Web Vitals (Tiêu chuẩn của Google):

  • LCP (Largest Contentful Paint): Mất bao lâu để nội dung chính hiện lên? (User có phải nhìn màn hình trắng không?)
  • INP (Interaction to Next Paint): Khi User bấm nút, bao lâu sau web phản hồi? (Web có bị đơ không?)
  • CLS (Cumulative Layout Shift): Web có bị nhảy lung tung khi đang đọc không?

Bên cạnh đó là các chỉ số sống còn khác:

  • JS Errors Rate: Có bao nhiêu user bấm nút "Thanh toán" mà không có gì xảy ra vì code JS bị crash ngầm?
  • API Success Rate (from Client): Backend trả về 200 OK, nhưng mạng user bị lag nên Frontend timeout. Backend không biết lỗi này, nhưng Frontend metrics thì có.

🛠 Công cụ "soi" số liệu cho Frontend:

  • Sentry / Rollbar: "Vua" bắt lỗi JS crash và màn hình trắng.
  • Google Lighthouse / PageSpeed Insights: Đo hiệu năng Lab data.
  • LogRocket / Hotjar: Quay lại video session của user (Session Replay) để xem họ thực sự gặp lỗi gì (cực kỳ hữu ích để debug UI).
  • Datadog RUM / New Relic Browser: Giám sát toàn diện từ trình duyệt.


3. Sự kết hợp hoàn hảo: Distributed Tracing


Đỉnh cao của Data Driven là khi bạn nối được số liệu của cả hai lại với nhau.

Bạn có thấy call api có trả về request id, nó điểm liên kết giữa Backend về Frontend

Khi có lỗi, bạn có thể tra ngược từ Backend về Frontend:

"Lỗi 500 này ở Backend là do User A, đang dùng iPhone 14, trên trình duyệt Safari, và họ đã thao tác click nút này 3 lần liên tiếp."

Lúc này, việc debug không còn là đoán mò nữa. Nó là khoa học chính xác.


Kết luận

"Show me the number" là tư duy giúp xóa bỏ ranh giới giữa Frontend và Backend.

  • Backend đưa ra số liệu để chứng minh hệ thống ổn định.
  • Frontend đưa ra số liệu để chứng minh trải nghiệm mượt mà (hoặc chỉ ra bottleneck do render/mạng).
  • Product Owner nhìn vào số liệu để ra quyết định kinh doanh.

Đừng để User là người duy nhất biết web của bạn đang bị lỗi.

Anh em Frontend và Backend đã "bắt tay" nhau trong việc monitor hệ thống chưa, hay team bạn mạnh rồi, mạnh ai lấy làm.