it-swarm-vi.com

Ưu điểm / nhược điểm của ứng dụng web "tách biệt"

Tôi đang trong quá trình thiết kế một ứng dụng web PHP/MySQL khá lớn (sắp có). Tôi đã đến một ngã ba đường cho đến kiến ​​trúc nội bộ; Tôi có thể xây dựng trang web dưới dạng một ứng dụng web "truyền thống" trong đó, khi bạn đưa ra yêu cầu, máy chủ sẽ tạo cho bạn một trang HTML, gửi cho bạn toàn bộ trang và trình duyệt hiển thị nó, hoặc, tôi có thể xây dựng nó dưới dạng "tách biệt "Ứng dụng web trong đó toàn bộ cấu trúc và mã HTML của ứng dụng được cung cấp cho trình duyệt khi tải ban đầu và ứng dụng sử dụng các cuộc gọi lại JavaScript để nhận dữ liệu cụ thể hoặc đưa ra các lệnh thông qua API hợp nhất. Ngoài ra, tôi dự định sẽ có nhiều phiên bản của trang web (máy tính để bàn, thiết bị di động, điện thoại di động iPhone/Android, thân thiện với công cụ tìm kiếm, v.v.) và đôi khi, thậm chí có thể là ứng dụng di động hoặc máy tính để bàn độc lập.

Những lợi thế/bất lợi nào mà bạn, với tư cách là nhà phát triển web, gặp phải với mỗi kiến ​​trúc này? Có một lý do rõ ràng tại sao tôi nên đi với người khác? Đây có phải là một thứ ưu tiên của nhà phát triển không?

3
Adam Maras

Trước hết, việc bạn có truy cập trang web nặng không đồng bộ hay không sẽ không ảnh hưởng nhiều đến khả năng xây dựng ứng dụng cho iPhone/Mobile và máy tính để bàn vì nó không liên quan gì đến chúng. Dù bằng cách nào bạn sẽ không thể sử dụng lại mã của mình.

Ngoài ra, các trang web không đồng bộ có thể chậm hoặc chậm hơn các trang web bình thường. Thông thường, loại chức năng đó được thêm vào vì một lý do, đặc biệt cho trải nghiệm người dùng phong phú. Sử dụng JavaScript có xu hướng làm tổn thương bạn về SEO vì các nhà lập trình web không thể hiểu đầy đủ ý định của JavaScript và vì vậy chủ yếu bỏ qua nó.

Tôi nghĩ rằng những gì bạn đang tìm kiếm là một cách để giảm chi phí phát triển của bạn bằng cách chỉ viết tầng chức năng (giữa) của bạn một lần và sử dụng cùng một thứ cho tất cả các ứng dụng của bạn. Trong trường hợp này tôi nghĩ rằng có giá trị nhưng thật lòng mà nói các loại kiến ​​trúc này khó thiết lập hơn và mất nhiều thời gian. Tôi có ý kiến ​​rằng bạn nên phát triển trang web của mình một cách tốt nhất có thể và giữ cho mã trung cấp của bạn mạnh nhất có thể. Theo cách đó, đã đến lúc thêm một ứng dụng iPhone hoặc bất cứ điều gì bạn sẽ có thể chuyển sang một mô hình với mức trung bình phổ biến dễ dàng hơn

Những gì tôi thực sự ủng hộ ở đây là thực hiện các bước bé. Đừng cố viết mã ngay bây giờ để xử lý những điều bạn chưa biết. Chỉ cần viết mã bạn cần và làm cho nó linh hoạt nhất có thể.

4
Ben Hoffman

Tôi nghĩ rằng ý tưởng về một ứng dụng "tách biệt" dựa nhiều vào JavaScript/AJAX sẽ khiến bạn gặp nhiều rắc rối. Một vài điều ngoài đỉnh đầu của tôi:

  1. Sẽ rất tệ cho SEO vì Google sẽ khó lập chỉ mục bất cứ điều gì.
  2. Sẽ rất khó để làm cho nó "có thể đánh dấu"
  3. Bạn sẽ có một thời gian khó khăn với các thiết bị di động vì nhiều người trong số họ có hỗ trợ javascript rất hạn chế (hoặc bị hỏng).
5
Eric Petroelje

Đầu tiên, không xúc phạm nếu câu trả lời này quá rõ ràng hoặc cơ bản. Việc bạn sử dụng "tách" thay vì các thuật ngữ như Ajax hoặc jQuery khiến tôi giả sử ít kinh nghiệm hơn với chủ đề này. Tất nhiên tôi có thể đọc sai câu hỏi, vì vậy tôi xin lỗi nếu đó là trường hợp.

Sử dụng cả hai, nhưng khôn ngoan

Hãy suy nghĩ về sự lựa chọn của bạn về các nhiệm vụ phía máy chủ hoặc phía máy khách về vị trí và cách thức thực hiện một nhiệm vụ hiệu quả nhất. Điều này sẽ giúp bạn kết xuất các trang một cách nhanh chóng (trên máy chủ), nhưng giảm tải cho trình duyệt nơi nó có ý nghĩa để làm điều đó. Và, sẽ có những vùng màu xám mà bạn chỉ cần thực hiện một cuộc gọi phán xét. Công việc của bạn là tìm một bộ phận lao động thông minh.

Những gì thuộc về phía máy chủ?

(Đây là một ví dụ cực đoan để minh họa điểm.) Giả sử bạn đang viết một ứng dụng web thực hiện một số loại tìm kiếm. Bạn không viết Javascript phía trình duyệt để gọi dịch vụ web PHP phía máy chủ để truy xuất toàn bộ cơ sở dữ liệu 2GB để "giải phóng máy chủ của bạn" và giảm tải tìm kiếm cho máy của người dùng. Những gì bạn làm là lấy các cụm từ tìm kiếm từ người dùng bằng một biểu mẫu, POST nó quay lại máy chủ để truy vấn cơ sở dữ liệu trực tiếp, sau đó gửi kết quả từ máy chủ về trình duyệt.

Logic ở đây là bản thân DB biết cách thực hiện tốt nhất truy vấn, máy chủ gần với dữ liệu nguồn hơn và ít dữ liệu phải được di chuyển xung quanh giữa các thành phần. Trình duyệt chỉ cần những gì nó hiển thị, vì vậy đừng gửi tất cả cho trình duyệt. (Không đề cập đến hiệu suất ngôn ngữ tương đối.)

Những gì thuộc về trình duyệt?

Mã bên trình duyệt là kịch bản "tách biệt" của bạn (nếu tôi hiểu chính xác). Nhưng để trình duyệt làm được hầu hết mọi thứ thông minh, nó phải có sự hợp tác của máy chủ.

Được rồi, bạn đã làm cho ứng dụng tìm kiếm của bạn hoạt động nhưng bạn muốn làm nổi bật nó bằng một chiếc quần lạ mắt Ajax. Viết một PHP dịch vụ web để lấy một vài chữ cái và trả về các cụm từ tìm kiếm phù hợp, a la tính năng "gợi ý tìm kiếm" của Bing , Google, v.v. Viết mã trình duyệt của bạn để chỉ đề xuất các thuật ngữ sau khi người dùng nhập ba hoặc bốn chữ cái, vì vậy danh sách đề xuất của bạn nhỏ. Quay lại máy chủ, lập chỉ mục cơ sở dữ liệu của bạn trên trường đó để tìm kiếm nhanh nhanh nhanh.

Ở đây suy nghĩ là "gợi ý tìm kiếm" là một tính năng mà phải được phân chia giữa máy chủ và máy khách. Trình duyệt có thể nhanh chóng xử lý các đống dữ liệu được nhắm mục tiêu, nhỏ. Máy chủ có thể lấy đống dữ liệu được nhắm mục tiêu nhỏ đó và cung cấp cho khách hàng. Một bộ phận kém sẽ dành cho máy chủ hiển thị danh sách quái vật (ví dụ: 500.000 mục) các giá trị trường có thể dưới dạng đảo XML được nhúng trong trang HTML, sau đó tìm kiếm trình duyệt theo kiểu người dùng. (a) gửi tất cả dữ liệu đó đến trình duyệt chậm, (b) tìm kiếm nó trong Javascript sẽ không bao giờ nhanh như để DB tìm kiếm nó, và (c) bạn có khả năng làm nổ tung máy của người dùng bằng cách nhồi nhét tất cả dữ liệu đó vào không gian ứng dụng trình duyệt của họ. Mặt khác, bạn cần đảm bảo chắc chắn rằng cuộc gọi Ajax đến máy chủ và truy vấn và trả về tiếp theo là siêu nhanh. Không có dilly-dallying xung quanh.

Vùng xám ở đâu?

Đây lại là một cuộc gọi phán xét. Ở trên, tôi đã nói về máy chủ thực hiện tìm kiếm, sau đó gửi kết quả đến trình duyệt. Nhưng, câu hỏi đặt ra, bạn có để trình duyệt gửi các cụm từ tìm kiếm với biểu mẫu và để máy chủ kết xuất trang kết quả hay bạn sử dụng Ajax/Javascript phía máy khách để gửi các cụm từ tìm kiếm và truy xuất kết quả, sau đó kết xuất nó trong một DIV để tránh làm mới trang? Cả hai đều hợp lệ. Tài nguyên khôn ngoan, không có lợi ích thực sự nào cả. Cách Ajax có thể cung cấp trải nghiệm người dùng tốt hơn, nhưng tùy thuộc vào ứng dụng và hoàn cảnh của bạn, có thể đưa ra một số thách thức khác (ví dụ: bảo mật).

Dòng dưới cùng

Sử dụng cả hai một cách thích hợp. Đừng bỏ qua suy nghĩ và tìm hiểu về hiệu suất và hiệu quả kiến ​​trúc. Di chuyển ít dữ liệu hơn, ít lần hơn. Bạn sẽ tải xuống máy chủ, cơ sở dữ liệu và trình duyệt của người dùng.

2
b w

Để có thể sử dụng lại mã, bạn luôn có thể xem XSLT để tạo trang đích và sau đó có giao diện XML/JSON cho AJAX (sử dụng giao diện XML cho trang đích XSLT).

Thông thường, bạn sẽ cho phép nội dung và tương tác hoạt động trên giao diện RESTful với tiền tố/json/... và/xml/... và Lưu trữ nội dung chính của bạn, được chuyển đổi thành đánh dấu qua XSLT trên/...

Bằng cách này, mọi người có thể truy cập vào bất kỳ trang nào và đột nhiên có toàn bộ trang web AJAX. Nhện có thể thu thập dữ liệu trang web của bạn và bạn đã tập trung vào nội dung/giao diện trước hết - có vẻ như là một chiến thắng/thắng.

Các trang web di động đôi khi cần các bố cục khác nhau (chỉ dành cho bất kỳ ai sử dụng iPhone?) Một chuyển đổi XSLT đơn giản tại đây hoặc ở đó để các khách hàng người dùng khác nhau có thể sử dụng lại mọi thứ bạn đã làm cho đến nay.

Hãy nhớ thiết kế cho đầu ra và điều hướng HTML đơn giản, các đơn giản hóa AJAX có thể làm theo.

PS - Thực hiện phía máy chủ biến đổi XSLT

1
Metalshark