Tại sao tôi định dạng ngày tháng trên máy chủ API?

Giới thiệu

Trong vai trò là một kỹ sư, tôi luôn có những "giải pháp" mà tôi hiểu rõ về những ưu và nhược điểm của chúng. Tuy nhiên, sau một thời gian dài làm việc, nhiều điều trở nên trực giác và tôi thường muốn xem xét lại quy trình suy nghĩ của mình. Bài viết này là một phần trong sự tự phản ánh của tôi về việc định dạng ngày tháng trong một hệ thống API.

Tôi có một cơ sở dữ liệu MongoDB lưu trữ dữ liệu với ngày tháng ở định dạng UTC. Tôi xây dựng một pipeline tổng hợp nhỏ để nhanh chóng thu thập báo cáo cho khách hàng, và thời gian mà khách hàng thấy là giờ Thái Lan (GMT+7).

Một ngày nọ, chúng tôi quyết định cho phép khách hàng tự tạo báo cáo từ giao diện người dùng. Vấn đề đặt ra là, liệu chúng tôi có nên định dạng ngày tháng ở cùng một nơi không?

Các lựa chọn định dạng ngày tháng

1. Định dạng ngày tháng trên Front-end

• Các framework như Angular có các toán tử pipe dễ sử dụng cho việc biến đổi dữ liệu chỉ nhằm mục đích hiển thị mà không làm thay đổi dữ liệu gốc.
• Đây là một phương pháp mà chúng tôi sẽ phải sử dụng nếu không kiểm soát máy chủ API của mình.
• Đồng thời, điều này có thể hợp lý nếu chúng tôi sử dụng một BFF (Backend for Frontend) chung và các frontend của chúng tôi sử dụng các định dạng ngày khác nhau.

Nhược điểm:

• Việc kiểm tra trên front-end có thể khó khăn hơn nhiều. Nếu chúng tôi đặt ngày tháng trong một trạng thái trước khi hiển thị, vòng đời render có thể ảnh hưởng đến việc gỡ lỗi.
• Nếu có lỗi, việc triển khai mới là cần thiết. Nếu frontend là một ứng dụng di động, có thể mất thêm thời gian chờ Apple/Google phê duyệt bản cập nhật.

2. Định dạng ngày tháng trên Máy chủ API

• Định dạng ở giai đoạn này có một số lợi thế như dễ dàng kiểm tra.
• Có thể cần một vòng lặp bổ sung để lặp qua và định dạng dữ liệu, nhưng nếu dữ liệu không quá lớn hoặc phức tạp, chi phí này không đáng kể.
• Chúng tôi nhận được sự phân chia rõ ràng về các mối quan tâm: frontend chỉ chịu trách nhiệm hiển thị dữ liệu, còn cơ sở dữ liệu chỉ cung cấp dữ liệu.
• Nếu có vấn đề, chúng tôi biết logic kinh doanh nằm ở đây.

3. Định dạng ngày tháng trong Cơ sở dữ liệu

• Nếu chọn cách này, chúng tôi có thể sử dụng cùng một truy vấn/pipeline hiện có để lấy dữ liệu.
• Nhưng việc kiểm tra logic định dạng ở cấp độ này có thể chỉ khả thi bằng cách viết một bài kiểm tra đơn vị trên máy chủ API để xác minh rằng pipeline projection được định dạng chính xác hoặc thực hiện kiểm tra smoke/integration.
• Chúng tôi mất đi sự phân chia rõ ràng về các mối quan tâm khi thêm logic bổ sung vào cơ sở dữ liệu.

Nhược điểm nghiêm trọng:

• Hạn chế lớn nhất là nút thắt cổ chai của hệ thống, đặc biệt trong các microservices, thường nằm ở cơ sở dữ liệu, điều này khó mở rộng hơn máy chủ API. Chúng tôi không thể cải thiện hiệu suất tại một điểm mà không xem xét mối quan hệ trên toàn bộ hệ thống.

So sánh các phương pháp

Phương pháp	Ưu điểm	Nhược điểm
Định dạng trên Front-end	Dễ dàng thay đổi định dạng cho từng giao diện	Khó kiểm tra và triển khai
Định dạng trên Máy chủ API	Dễ dàng kiểm tra, rõ ràng về logic	Cần thêm vòng lặp cho dữ liệu lớn
Định dạng trong Cơ sở dữ liệu	Sử dụng lại truy vấn hiện có	Mất phân chia rõ ràng, khó khăn trong kiểm tra

Các thực hành tốt nhất

• Luôn giữ logic định dạng tách biệt giữa frontend và backend để dễ quản lý và bảo trì.
• Kiểm tra kỹ lưỡng các thay đổi trong logic định dạng để đảm bảo không phát sinh lỗi trong quá trình hiển thị.

Những cạm bẫy phổ biến

• Không rõ ràng trong việc phân chia trách nhiệm giữa frontend và backend.
• Quá phụ thuộc vào logic cơ sở dữ liệu có thể dẫn đến khó khăn trong việc bảo trì và nâng cấp.

Mẹo hiệu suất

• Hạn chế số lượng dữ liệu lớn khi định dạng để cải thiện hiệu suất.
• Sử dụng caching cho các kết quả đã định dạng để giảm tải cho máy chủ API.

Giải quyết sự cố

• Nếu gặp lỗi định dạng, hãy kiểm tra kỹ các quy trình biên dịch và kiểm tra logic định dạng.
• Sử dụng các công cụ gỡ lỗi để theo dõi luồng dữ liệu và logic trong máy chủ API.

Kết luận

Qua bài viết này, tôi hy vọng đã làm rõ lý do vì sao việc định dạng ngày tháng trên máy chủ API là một quyết định hợp lý. Mỗi lựa chọn đều có ưu và nhược điểm riêng, và quyết định cuối cùng phụ thuộc vào yêu cầu cụ thể của dự án. Hãy chia sẻ suy nghĩ và ý kiến của bạn về vấn đề này trong cộng đồng phát triển để cùng nhau học hỏi và cải thiện.

Câu hỏi thường gặp (FAQ)

1. Tại sao nên định dạng ngày tháng trên máy chủ API?

   • Giúp dễ dàng kiểm tra và tách biệt trách nhiệm giữa frontend và backend.

2. Có những phương pháp nào để định dạng ngày tháng?

   • Có ba phương pháp chính: trên frontend, trên máy chủ API và trong cơ sở dữ liệu.

3. Những nhược điểm của việc định dạng trong cơ sở dữ liệu là gì?

   • Khó kiểm tra, mất phân chia trách nhiệm và có thể gây ra nút thắt cổ chai trong hiệu suất hệ thống.