Xây dựng ứng dụng web ở phía máy chủ và phía máy khách so với kết hợp? [đóng cửa]


27

Hiện tại có nhiều cách tiếp cận để xây dựng các ứng dụng web:

1. Chỉ phía máy chủ

Đây là một cách tiếp cận cổ điển nơi bạn kết xuất các trang trên máy chủ bằng khung web như Ruby on Rails, Django, Express, Play! Khung và vv

Quy trình công việc điển hình : Xây dựng tất cả logic kinh doanh, mô hình và xem mẫu trên máy chủ theo khung bạn chọn.

2. API khách hàng + API

Tương đối cách đây không lâu, toàn bộ cộng đồng web đã bắt đầu xây dựng các ứng dụng phía máy khách trong Angular, Backbone, Ember và một vài chục khung JavaScript MV * khác. Và bây giờ chúng tôi cũng có React.js tham gia bữa tiệc.

CẬP NHẬT : Không có sự hiểu lầm. Những gì tôi có nghĩa là chỉ phía khách hàng là hoàn toàn tách biệt mối quan tâm. Bạn có máy chủ API REST và ứng dụng phía máy khách nói chuyện với máy chủ đó. Tùy thuộc vào trường hợp sử dụng của bạn, rất có thể, bạn sẽ không bao giờ có ứng dụng chỉ dành cho khách hàng thực sự không kết nối với back-end để xác thực hoặc duy trì dữ liệu.

Quy trình làm việc điển hình : Dành hàng giờ để quyết định Angular vs Backbone vs Ember vs X. Sau đó, bạn xây dựng tuyến đường, mô hình, chế độ xem, bộ điều khiển của mình trên máy khách. Sau khi bạn hoàn thành, bây giờ xây dựng mô hình, bộ điều khiển, tuyến đường trên máy chủ. Theo một cách nào đó, bạn đang làm gấp đôi số lượng công việc.

3. Lai

Tôi không biết nhiều về cách sử dụng phương pháp này, nhưng nếu tôi đoán, bạn sẽ hiển thị các khung nhìn của mình (Khung nhìn của khung MVC) trên máy chủ. Kết quả là bạn nhận được hỗ trợ SEO cộng với tải trang nhanh hơn.

Trên lai phía trước có Airbnb của rendr được cho là kết hợp xương sống và thể hiện với nhau.

Eric Florenzo đã đăng trên blog của mình ngày hôm nay: React: Cuối cùng, một ngăn xếp web máy chủ / máy khách tuyệt vời .

Số lượng cách để xây dựng các ứng dụng web chỉ là quá nhiều. Và đối với ai đó đang học phát triển web thì điều này có thể trở thành một vấn đề. Làm thế nào để một người quyết định sử dụng phương pháp nào để xây dựng ứng dụng tiếp theo của họ?


1
"Chỉ phía khách hàng: ... Sau khi bạn hoàn thành, bây giờ hãy xây dựng các mô hình, bộ điều khiển, tuyến đường trên máy chủ." Điều này không phân tích cú pháp.
dùng16764

@ user16764 đã cập nhật câu hỏi của tôi.
Xếp hạng R

Câu trả lời:


13

Tôi nghĩ rằng bạn đã hoàn toàn hiểu nhầm "Chỉ phía khách hàng".

Đầu tiên, nó phải được dán nhãn "Trung tâm khách hàng". Toàn bộ điểm của các khung như Angular là các phần "VC" của MVC được triển khai hoàn toàn trong trình duyệt trong Javascript. Logic mức "M" cao hơn của phần "M" - Model - được triển khai trong trình duyệt và logic "CRUD" cấp thấp hơn được triển khai trên máy chủ.

Logic kinh doanh được phát triển một lần. Logic xem được phát triển một lần. Logic điều khiển được phát triển một lần - tất cả trong khung Javascript được lựa chọn. Logic truy cập dữ liệu cũng chỉ được phát triển một lần nhưng lần này trên bất kỳ khung RESTy hoặc SOAPy nào bạn chọn ở phía máy chủ.

Trong các trường hợp cực đoan, bạn có thể triển khai Mô hình hoàn toàn trong máy khách, nếu chỉ có thể truy cập dữ liệu từ một trình duyệt trên một máy và có thể xử lý dữ liệu mỗi khi chọn tùy chọn "Xóa cookie".


Thật sự rất khó để không phát triển ít nhất một số logic kinh doanh hai lần. Để có trải nghiệm người dùng tốt, bạn cần đảm bảo người dùng nhập email của họ để tiếp tục. Nhưng bạn không thể tin tưởng khách hàng nên bạn cũng cần thực hiện quy tắc trên máy chủ. Ít nhất tôi thực sự hy vọng bạn không nói triển khai logic nghiệp vụ trong JS trên máy khách.
Andy

@Andy đó chính xác là quan điểm của tôi. Khi tôi xây dựng một ứng dụng Ember, việc xác thực mẫu cơ bản phải được thực hiện trên máy khách, nhưng nó cũng cần phải được thực hiện trên máy chủ. Tôi đã gặp rắc rối nghiêm trọng một lần vì không xác thực dữ liệu của mình trên máy chủ và hoàn toàn tin tưởng vào máy khách.
Xếp hạng R

Andy et all - hãy xem tài liệu google. Ngoài việc tải tài liệu, bảng tính, vv từ máy chủ, lưu nó ở cuối và lấy bản sao lưu thường xuyên ở giữa mọi thứ khác diễn ra trong trình duyệt của bạn. Trang web Google Docs chỉ hoạt động như một máy chủ lưu trữ dữ liệu và máy chủ xác thực.
James Anderson

3
@JamesAnderson Google Docs khá khác so với nói một cửa hàng trực tuyến. Bạn đang chỉnh sửa tài liệu của riêng mình, nó chỉ là một kho dữ liệu mà họ lưu mà không thực sự quan tâm đến ý nghĩa của dữ liệu. Nhưng bạn có thực sự nghĩ rằng việc xác nhận đơn hàng chỉ nên được thực hiện trên máy khách? Bạn chỉ yêu cầu mọi người cung cấp cho mình các sản phẩm miễn phí nếu đó là cách bạn xây dựng một ứng dụng như vậy. Có vẻ như bạn cũng cho rằng Google trên thực tế không thực hiện bất kỳ xác thực dữ liệu nào ở cuối máy chủ. Thực sự không có cách nào để chúng ta biết chuyện gì đang xảy ra.
Andy

9

Câu trả lời cho câu hỏi là nó phụ thuộc vào yêu cầu. Một cái nhìn ít nhất về lịch sử phát triển của "web" cho thấy văn hóa cao bồi nơi nói chuyện với các bên liên quan, khách hàng, thu thập yêu cầu, thường bị bỏ qua.

Tôi đã may mắn được tham dự một cuộc nói chuyện vài năm trước, nơi tôi nghe thấy một điều thực sự bế tắc với tôi: "bạn chọn thiết kế để đáp ứng các yêu cầu, chứ không phải các yêu cầu để đáp ứng thiết kế". Vì vậy, khi đối mặt với một câu hỏi như thế này, bạn cần phải đi tìm hiểu những gì thực sự cần thiết bởi những người đang yêu cầu bạn xây dựng phần mềm này.

Công việc của bạn là giải thích những ưu và nhược điểm đằng sau mỗi cách tiếp cận.


1
Cảm ơn. Những gì bạn đang nói có ý nghĩa. Tôi đã hy vọng có một "viên đạn bạc", một cách thực sự để làm mọi việc. Tôi đã bắt đầu với một khung web Python có tên Django vào năm 2011. Ngay sau đó đã có một sự thúc đẩy lớn đối với các khung công tác MV * phía máy khách như Backbone, Angular, Ember. Và đột nhiên cách Rails và Django xây dựng các ứng dụng web đã trở nên lỗi thời. Nhưng ngày nay, dường như chúng ta đang lùi một bước và trộn phía máy khách với phía máy chủ một lần nữa để đạt được hiệu suất tốt hơn.
Xếp hạng R

Đáng buồn thay, không, không có viên đạn bạc. :). Tuy nhiên, mẹo là phải có đủ sự hiểu biết về cách các mảnh ghép khớp với nhau để xác định kết quả tốt nhất cho nhiệm vụ trong tay và cũng để hỗ trợ văn hóa tái cấu trúc tàn nhẫn để bạn luôn có thể thay đổi mọi thứ nếu hướng đi ban đầu của bạn không hiệu quả.
RibaldEddie

1
Điều này là tốt và tất cả nhưng đôi khi cả hai cách tiếp cận đều khả thi và trong trường hợp này bạn cần một cái gì đó khác hơn là yêu cầu để đưa ra quyết định.
Ced

5

Tôi nghĩ một trong những điểm chính của các cách tiếp cận và khung mới hơn là có ít sự kết hợp giữa các công nghệ mặt trước và công nghệ mặt sau.

Ý tưởng là bạn có thể sử dụng bất kỳ khung nào trên máy khách và kéo dữ liệu và / hoặc lượt xem từ bất kỳ số nguồn nào bất kể khung phía máy chủ.

Điều này cho phép chúng tôi chọn các công cụ tốt nhất để hoàn thành công việc và các lựa chọn của chúng tôi có thể phát triển độc lập.

Phải thừa nhận rằng, tôi chưa sử dụng Angular hoặc Backbone nên tôi không thể đưa ra bất kỳ khuyến nghị có kinh nghiệm nào. Ngăn xếp cơ sở hiện tại của tôi bao gồm các máy chủ mvc mỏng nhất hoặc các dịch vụ yên tĩnh mà tôi có thể tìm thấy. Chủ yếu là cung cấp các mẫu và dữ liệu. Dữ liệu được kết xuất và / hoặc dữ liệu tiếp theo được truy xuất phía máy khách bằng cách sử dụng phần lớn chỉ là javascript, jquery và css đơn giản.

Tôi bắt đầu ở đây và xây dựng dựa trên nó là tôi cần. Lợi ích của phương pháp này là rõ ràng khi bạn nghĩ về việc hỗ trợ nhiều nền tảng máy khách - trình duyệt, thiết bị di động, v.v. Nếu bạn cần kết xuất cụ thể của máy khách, bạn không cần phải thực hiện các thay đổi lớn về phía máy chủ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.