Triển khai các dịch vụ backend riêng biệt cho từng ứng dụng frontend hoặc giao diện cụ thể. Mô hình này rất hữu ích để tránh việc phải tùy chỉnh một backend duy nhất cho nhiều giao diện khác nhau. Sam Newman là người đã mô tả mô hình này.
Bối cảnh và Vấn đề
Khi phát triển một ứng dụng web dành cho máy tính để bàn, thường thì một dịch vụ backend sẽ được xây dựng song song để cung cấp các tính năng cần thiết cho giao diện đó. Tuy nhiên, khi ứng dụng phát triển và cần mở rộng sang nền tảng di động, cùng một backend sẽ được sử dụng để phục vụ cả giao diện web và di động. Điều này khiến backend phải đáp ứng các yêu cầu khác nhau từ cả hai giao diện.
Thiết bị di động có những hạn chế riêng về kích thước màn hình, hiệu suất và khả năng hiển thị so với trình duyệt trên máy tính để bàn. Do đó, các yêu cầu của backend cho ứng dụng di động sẽ khác biệt so với giao diện web.
Sự khác biệt này tạo ra các yêu cầu đối lập cho backend. Việc thay đổi thường xuyên để đáp ứng cả hai giao diện dẫn đến điểm nghẽn trong quá trình phát triển. Các đội phát triển giao diện riêng biệt sẽ khiến backend trở thành một gánh nặng khi phải duy trì và cân bằng các yêu cầu đối lập từ các đội này.
Khi sự phát triển backend trở nên phức tạp, một đội riêng biệt có thể được tạo ra để quản lý và duy trì nó. Điều này dẫn đến sự ngắt kết nối giữa các đội phát triển giao diện và backend, gây khó khăn trong việc tích hợp thay đổi.
Giải pháp
Tạo một backend riêng cho mỗi giao diện người dùng. Tối ưu hóa hành vi và hiệu suất của mỗi backend để phù hợp nhất với nhu cầu của từng môi trường frontend mà không lo ảnh hưởng đến trải nghiệm của các frontend khác.
Bằng cách làm này, mỗi backend sẽ nhỏ hơn, ít phức tạp hơn và nhanh hơn so với một backend đa năng cố gắng đáp ứng tất cả các giao diện. Mỗi đội phát triển giao diện sẽ có quyền tự chủ để kiểm soát backend của mình, không phụ thuộc vào một đội backend tập trung. Điều này mang lại sự linh hoạt trong việc lựa chọn ngôn ngữ, lịch phát hành, ưu tiên công việc và tích hợp tính năng.
Các Vấn đề và Cân nhắc
- Số lượng backend cần triển khai: Nếu các giao diện khác nhau sẽ thực hiện các yêu cầu giống nhau, hãy xem xét liệu có cần thiết phải triển khai một backend cho mỗi giao diện hay không.
- Sao chép mã giữa các dịch vụ: Có khả năng sẽ xảy ra khi áp dụng mô hình này.
- Logic cụ thể cho frontend: Các dịch vụ backend nên chỉ chứa logic và hành vi cụ thể của khách hàng. Logic kinh doanh chung và các tính năng toàn cầu nên được quản lý ở nơi khác trong ứng dụng của bạn.
- Phản ánh trong trách nhiệm của đội phát triển: Nghĩ về cách mô hình này sẽ ảnh hưởng đến sự phân chia trách nhiệm giữa các đội.
- Thời gian triển khai: Xem xét thời gian cần thiết để triển khai mô hình này và liệu có gây ra nợ kỹ thuật trong quá trình hỗ trợ backend đa năng hiện có hay không.
Khi Nào Nên Sử Dụng Mô Hình Này
- Backend chia sẻ hoặc đa năng: Khi dịch vụ backend này cần được duy trì với chi phí phát triển đáng kể.
- Tối ưu hóa backend: Khi bạn muốn tối ưu hóa backend cho các yêu cầu của các giao diện khách hàng cụ thể.
- Tùy chỉnh backend: Khi cần tùy chỉnh backend đa năng để đáp ứng nhiều giao diện.
- Ngôn ngữ lập trình phù hợp: Khi một ngôn ngữ lập trình phù hợp hơn cho backend của một giao diện cụ thể, nhưng không phải cho tất cả các giao diện.
Mô Hình Này Có Thể Không Phù Hợp Khi
- Yêu cầu tương tự nhau: Khi các giao diện thực hiện các yêu cầu giống hoặc tương tự nhau đến backend.
- Chỉ có một giao diện: Khi chỉ có một giao diện được sử dụng để tương tác với backend.
Để lại một bình luận