Ứng dụng Trang đơn: ưu điểm và nhược điểm [đóng]

Tôi đã đọc về SPA và nó có lợi thế. Tôi thấy hầu hết trong số họ không thuyết phục. Có 3 ưu điểm khơi dậy sự nghi ngờ của tôi.

Câu hỏi: Bạn có thể đóng vai trò là người ủng hộ SPA và chứng minh rằng tôi sai về ba tuyên bố đầu tiên không?

                              === ADVANTAGES ===

1. SPA cực kỳ tốt cho các trang web rất nhạy:

Kết xuất phía máy chủ khó thực hiện đối với tất cả các trạng thái trung gian - trạng thái chế độ xem nhỏ không ánh xạ tốt tới URL.

Các ứng dụng trang đơn được phân biệt bởi khả năng vẽ lại bất kỳ phần nào của giao diện người dùng mà không yêu cầu máy chủ khứ hồi để truy xuất HTML. Điều này đạt được bằng cách tách dữ liệu khỏi việc trình bày dữ liệu bằng cách có một lớp mô hình xử lý dữ liệu và lớp xem đọc từ các mô hình.

Có gì sai khi giữ một lớp mô hình cho phi SPA? Liệu SPA có kiến ​​trúc tương thích duy nhất với MVC ở phía máy khách?

2. Với SPA, chúng tôi không cần sử dụng các truy vấn bổ sung vào máy chủ để tải xuống các trang.

Hah, và có bao nhiêu trang người dùng có thể tải xuống trong khi truy cập trang web của bạn? Hai, ba? Thay vào đó, xuất hiện một vấn đề bảo mật khác và bạn cần tách trang đăng nhập, trang quản trị, v.v. thành các trang riêng biệt. Đổi lại, nó xung đột với kiến ​​trúc SPA.

3. Có thể có bất kỳ lợi thế khác? Đừng nghe về bất cứ điều gì khác ..

                            === DISADVANTAGES ===

1. Khách hàng phải kích hoạt javascript.
2. Chỉ có một điểm vào trang web.
3. Bảo vệ.

PS Tôi đã làm việc trên các dự án SPA và phi SPA. Và tôi đang hỏi những câu hỏi đó bởi vì tôi cần phải hiểu sâu hơn. Không có nghĩa là làm hại những người ủng hộ SPA. Đừng yêu cầu tôi đọc thêm một chút về SPA. Tôi chỉ muốn nghe những cân nhắc của bạn về điều đó.

Hãy xem một trong những trang web phổ biến nhất về SPA, GMail.

1. SPA cực kỳ tốt cho các trang web rất nhạy:

Kết xuất phía máy chủ không khó như trước đây với các kỹ thuật đơn giản như giữ #hash trong URL hoặc gần đây hơn là HTML5pushState . Với cách tiếp cận này, trạng thái chính xác của ứng dụng web được nhúng vào URL trang. Như trong Gmail mỗi khi bạn mở thư, một thẻ băm đặc biệt sẽ được thêm vào URL. Nếu được sao chép và dán vào cửa sổ trình duyệt khác có thể mở chính xác cùng một thư (miễn là chúng có thể xác thực). Cách tiếp cận này ánh xạ trực tiếp đến một chuỗi truy vấn truyền thống hơn, sự khác biệt chỉ đơn thuần là trong thực thi. Với HTML5 PushState (), bạn có thể loại bỏ #hashvà sử dụng các URL hoàn toàn cổ điển có thể giải quyết trên máy chủ theo yêu cầu đầu tiên và sau đó tải qua ajax cho các yêu cầu tiếp theo.

2. Với SPA, chúng tôi không cần sử dụng các truy vấn bổ sung vào máy chủ để tải xuống các trang.

Số lượng trang người dùng tải xuống trong khi truy cập vào trang web của tôi ?? thực sự có bao nhiêu thư được đọc khi anh ấy / cô ấy mở tài khoản mail của mình. Tôi đọc> 50 cùng một lúc. bây giờ cấu trúc của các thư gần như giống nhau. nếu bạn sẽ sử dụng sơ đồ kết xuất phía máy chủ thì máy chủ sẽ kết xuất nó theo mọi yêu cầu (trường hợp điển hình). - mối quan tâm bảo mật - bạn nên / không nên giữ các trang riêng cho quản trị viên / đăng nhập mà hoàn toàn phụ thuộc vào cấu trúc trang web của bạn, ví dụ như làm cho một trang web SPA không có nghĩa là bạn mở tất cả các điểm cuối cho tất cả người dùng Tôi có nghĩa là tôi sử dụng các hình thức auth với trang web spa của tôi. - trong khung công tác SPA được sử dụng nhiều nhất Angular JS, nhà phát triển có thể tải toàn bộ ngôi đền html từ trang web để có thể được thực hiện tùy thuộc vào mức độ xác thực của người dùng. tải trước html cho tất cả các loại auth là '

3. Có thể có lợi thế nào khác? Đừng nghe về bất cứ điều gì khác ..

• những ngày này, bạn có thể giả định rằng máy khách sẽ có các trình duyệt hỗ trợ javascript.
• chỉ có một điểm vào của trang web. Như tôi đã đề cập trước đây có thể duy trì trạng thái, bạn có thể có bất kỳ số điểm nhập cảnh nào bạn muốn nhưng bạn nên có một điểm chắc chắn.
• ngay cả trong một người dùng SPA chỉ nhìn thấy những gì anh ta có quyền thích hợp. bạn không cần phải tiêm mọi thứ cùng một lúc. tải các mẫu khác nhau của html và async javascript cũng là một phần hợp lệ của SPA.

Những lợi thế mà tôi có thể nghĩ đến là:

1. hiển thị html rõ ràng cần một số tài nguyên bây giờ mỗi người dùng truy cập trang web của bạn đang làm điều này. cũng không chỉ hiển thị các logic lớn hiện được thực hiện phía máy khách thay vì phía máy chủ.
2. vấn đề về thời gian ngày - Tôi chỉ cung cấp cho khách hàng thời gian UTC là định dạng được đặt sẵn và thậm chí không quan tâm đến các múi giờ tôi để javascript xử lý nó. đây là lợi thế lớn cho việc tôi phải đoán múi giờ dựa trên vị trí xuất phát từ IP của người dùng.
3. Đối với tôi, trạng thái được duy trì tốt hơn trong một SPA bởi vì một khi bạn đã đặt một biến bạn biết nó sẽ ở đó. điều này mang lại cảm giác phát triển một ứng dụng hơn là một trang web. điều này thường giúp ích rất nhiều trong việc tạo ra các trang web như foodpanda, flipkart, amazon. bởi vì nếu bạn không sử dụng trạng thái phía máy khách, bạn đang sử dụng các phiên đắt tiền.
4. các trang web chắc chắn rất nhạy - tôi sẽ lấy một ví dụ cực đoan cho việc thử làm một máy tính trong một trang web không phải là SPA (tôi biết điều đó thật kỳ lạ).

Cập nhật từ Nhận xét

Dường như không có ai đề cập đến ổ cắm và bỏ phiếu dài. Nếu bạn đăng xuất từ ​​một khách hàng khác nói ứng dụng di động, thì trình duyệt của bạn cũng nên đăng xuất. Nếu bạn không sử dụng SPA, bạn phải tạo lại kết nối ổ cắm mỗi khi có chuyển hướng. Điều này cũng sẽ hoạt động với bất kỳ cập nhật nào trong dữ liệu như thông báo, cập nhật hồ sơ, v.v.

Một viễn cảnh khác: Ngoài trang web của bạn, dự án của bạn có liên quan đến một ứng dụng di động gốc không? Nếu có, rất có thể bạn sẽ cung cấp dữ liệu thô cho ứng dụng gốc đó từ máy chủ (tức là JSON) và thực hiện xử lý phía máy khách để hiển thị nó, đúng không? Vì vậy, với xác nhận này, bạn C ALNG đang thực hiện mô hình kết xuất phía máy khách. Bây giờ câu hỏi trở thành, tại sao bạn không nên sử dụng cùng một mô hình cho phiên bản trang web của dự án của bạn? Loại không có trí tuệ. Sau đó, câu hỏi đặt ra là bạn có muốn hiển thị các trang phía máy chủ chỉ vì lợi ích SEO và sự tiện lợi của các URL có thể chia sẻ / đánh dấu được không

Tôi là một người thực dụng, vì vậy tôi sẽ cố gắng xem xét điều này về chi phí và lợi ích.

Lưu ý rằng đối với bất kỳ nhược điểm nào tôi đưa ra, tôi nhận ra rằng chúng có thể giải quyết được. Đó là lý do tại sao tôi không xem bất cứ thứ gì là đen trắng, mà là chi phí và lợi ích.

Ưu điểm

• Theo dõi trạng thái dễ dàng hơn - không cần sử dụng cookie, gửi biểu mẫu, lưu trữ cục bộ, lưu trữ phiên, v.v để ghi nhớ trạng thái giữa 2 lần tải trang.
• Nội dung tấm nồi hơi có trên mỗi trang (đầu trang, chân trang, logo, biểu ngữ bản quyền, v.v.) chỉ tải một lần cho mỗi phiên trình duyệt thông thường.
• Không có độ trễ trên không khi chuyển đổi "trang".

Nhược điểm

• Giám sát hiệu suất - bị trói tay: Hầu hết các giải pháp giám sát hiệu suất ở cấp trình duyệt tôi chỉ thấy tập trung vào thời gian tải trang, như thời gian đến byte đầu tiên, thời gian để tạo DOM, chuyến đi vòng quanh mạng cho HTML, sự kiện tải, v.v. Cập nhật trang tải sau thông qua AJAX sẽ không được đo. Có các giải pháp cho phép bạn sử dụng mã của mình để ghi lại các biện pháp rõ ràng, như khi nhấp vào liên kết, bắt đầu hẹn giờ, sau đó kết thúc bộ hẹn giờ sau khi hiển thị kết quả AJAX và gửi phản hồi đó. Relic mới, ví dụ, hỗ trợ chức năng này. Bằng cách sử dụng một SPA, bạn đã tự buộc mình vào một vài công cụ có thể.
• Kiểm tra bảo mật / thâm nhập - bị trói tay: Quét bảo mật tự động có thể gặp khó khăn khi khám phá các liên kết khi toàn bộ trang của bạn được xây dựng động bởi khung SPA. Có thể có giải pháp cho vấn đề này, nhưng một lần nữa, bạn đã tự giới hạn mình.
• Đóng gói: Rất dễ gặp phải tình huống khi bạn đang tải xuống tất cả các mã cần thiết cho toàn bộ trang web khi tải trang ban đầu, có thể thực hiện khủng khiếp cho các kết nối băng thông thấp. Bạn có thể gói các tệp JavaScript và CSS của mình để cố gắng tải các khối tự nhiên hơn khi bạn đi, nhưng bây giờ bạn cần duy trì ánh xạ đó và xem các tệp không mong muốn để được kéo vào thông qua các phụ thuộc không thực hiện được (chỉ xảy ra với tôi). Một lần nữa, có thể giải quyết, nhưng với một chi phí.
• Tái cấu trúc Big bang: Nếu bạn muốn thực hiện một thay đổi lớn về kiến ​​trúc, như nói, hãy chuyển từ khung này sang khung khác, để giảm thiểu rủi ro, bạn nên thực hiện các thay đổi gia tăng. Đó là, bắt đầu sử dụng cái mới, di chuyển trên một số cơ sở, như mỗi trang, mỗi tính năng, v.v., sau đó bỏ cái cũ sau. Với ứng dụng nhiều trang truyền thống, bạn có thể chuyển một trang từ Angular sang React, sau đó chuyển một trang khác trong lần chạy nước rút tiếp theo. Với một SPA, đó là tất cả hoặc không có gì. Nếu bạn muốn thay đổi, bạn phải thay đổi toàn bộ ứng dụng trong một lần.
• Độ phức tạp của điều hướng: Công cụ tồn tại để giúp duy trì bối cảnh điều hướng trong các SPA, như history.js, Angular 2, hầu hết đều dựa vào khung URL (#) hoặc API lịch sử mới hơn. Nếu mỗi trang là một trang riêng biệt, bạn không cần bất kỳ trang nào trong số đó.
• Sự phức tạp của việc tìm ra mã: Chúng tôi tự nhiên nghĩ về các trang web như các trang. Một ứng dụng nhiều trang thường phân vùng mã theo trang, hỗ trợ khả năng bảo trì.

Một lần nữa, tôi nhận ra rằng mỗi một trong những vấn đề này đều có thể giải quyết được, bằng một số giá. Nhưng có một điểm mà bạn đang dành tất cả thời gian để giải quyết các vấn đề mà bạn có thể tránh được ngay từ đầu. Nó trở lại với những lợi ích và tầm quan trọng của chúng đối với bạn.

Nhược điểm

1. Khách hàng phải kích hoạt javascript. Vâng, đây là một bất lợi rõ ràng của SPA. Trong trường hợp của tôi, tôi biết rằng tôi có thể mong đợi người dùng của mình kích hoạt JavaScript. Nếu bạn không thể thì bạn không thể làm một SPA, thời gian. Điều đó giống như cố gắng triển khai ứng dụng .NET vào máy mà không cài đặt .NET Framework.

2. Chỉ có một điểm vào trang web. Tôi giải quyết vấn đề này bằng SammyJS . 2-3 ngày làm việc để thiết lập định tuyến đúng cách và mọi người sẽ có thể tạo dấu trang liên kết sâu vào ứng dụng của bạn hoạt động chính xác. Máy chủ của bạn sẽ chỉ cần hiển thị một điểm cuối - điểm cuối "cung cấp cho tôi HTML + CSS + JS cho ứng dụng này" (nghĩ về nó như một vị trí tải xuống / cập nhật cho ứng dụng được biên dịch trước) - và JavaScript phía máy khách bạn viết sẽ xử lý các mục thực tế vào ứng dụng.

3. Bảo mật.Vấn đề này không phải là duy nhất đối với các SPA, bạn phải xử lý bảo mật theo cách chính xác giống như khi bạn có ứng dụng máy chủ-máy khách "trường học cũ" (mô hình HATEOAS sử dụng Hypertext để liên kết giữa các trang). Chỉ là người dùng đang thực hiện các yêu cầu chứ không phải JavaScript của bạn và kết quả là bằng HTML chứ không phải JSON hoặc một số định dạng dữ liệu. Trong ứng dụng không phải là SPA, bạn phải bảo mật các trang riêng lẻ trên máy chủ, trong khi đó, trong ứng dụng SPA, bạn phải bảo mật các điểm cuối dữ liệu. (Và, nếu bạn không muốn khách hàng của mình có quyền truy cập vào tất cả mã, thì bạn cũng phải tách JavaScript có thể tải xuống thành các khu vực riêng biệt. Tôi chỉ cần gắn nó vào hệ thống định tuyến dựa trên SammyJS của mình để trình duyệt chỉ yêu cầu những thứ mà khách hàng biết rằng nó nên có quyền truy cập, dựa trên tải ban đầu về vai trò của người dùng,

Ưu điểm

1. Một lợi thế kiến ​​trúc chính của một SPA (hiếm khi được đề cập) trong nhiều trường hợp là giảm đáng kể "độ chát" của ứng dụng của bạn. Nếu bạn thiết kế nó đúng cách để xử lý hầu hết việc xử lý trên máy khách (toàn bộ điểm, sau tất cả), thì số lượng yêu cầu đến máy chủ (đọc "khả năng xảy ra 503 lỗi làm hỏng trải nghiệm người dùng của bạn") sẽ giảm đáng kể. Trên thực tế, một SPA cho phép thực hiện xử lý ngoại tuyến hoàn toàn, rất lớn trong một số trường hợp.

2. Hiệu suất chắc chắn tốt hơn với kết xuất phía máy khách nếu bạn làm đúng, nhưng đây không phải là lý do hấp dẫn nhất để xây dựng một SPA. (Rốt cuộc, tốc độ mạng đang được cải thiện.) Đừng làm trường hợp cho SPA trên cơ sở này một mình.

3. Tính linh hoạt trong thiết kế giao diện người dùng của bạn có lẽ là lợi thế lớn khác mà tôi đã tìm thấy. Khi tôi đã xác định API của mình (với SDK bằng JavaScript), tôi có thể viết lại hoàn toàn phần đầu của mình bằng không ảnh hưởng đến máy chủ ngoài một số tệp tài nguyên tĩnh. Hãy thử làm điều đó với một ứng dụng MVC truyền thống! :) (Điều này trở nên có giá trị khi bạn phải triển khai trực tiếp và tính nhất quán phiên bản API của mình.)

Vì vậy, điểm mấu chốt: Nếu bạn cần xử lý ngoại tuyến (hoặc ít nhất muốn khách hàng của mình có thể sống sót khi bị cúp máy chủ thường xuyên) - giảm đáng kể chi phí phần cứng của riêng bạn - và bạn có thể sử dụng JavaScript và các trình duyệt hiện đại, thì bạn cần có SPA. Trong các trường hợp khác, đó là một sự đánh đổi nhiều hơn.

Một nhược điểm lớn của SPA - SEO. Chỉ gần đây, Google và Bing mới bắt đầu lập chỉ mục các trang dựa trên Ajax bằng cách thực thi JavaScript trong khi thu thập thông tin và trong nhiều trường hợp các trang đang bị lập chỉ mục không chính xác.

Trong khi phát triển SPA, bạn sẽ buộc phải xử lý các sự cố SEO, có thể bằng cách hiển thị lại tất cả trang web của bạn và tạo ảnh chụp nhanh html tĩnh để sử dụng trình thu thập thông tin. Điều này sẽ đòi hỏi một sự đầu tư vững chắc vào một cơ sở hạ tầng thích hợp.

Cập nhật 19.06.16:

Kể từ khi viết câu trả lời này cách đây một thời gian, tôi có được nhiều kinh nghiệm hơn với Ứng dụng trang đơn (cụ thể là AngularJS 1.x) - vì vậy tôi có thêm thông tin để chia sẻ.

Theo tôi, nhược điểm chính của ứng dụng SPA là SEO, khiến chúng chỉ giới hạn ở loại ứng dụng "bảng điều khiển". Ngoài ra, bạn sẽ có một thời gian khó khăn hơn nhiều với bộ nhớ đệm, so với các giải pháp cổ điển. Ví dụ, trong bộ nhớ đệm ASP.NET rất dễ dàng - chỉ cần bật OutputCaching và bạn vẫn ổn: toàn bộ trang HTML sẽ được lưu vào bộ đệm theo URL (hoặc bất kỳ tham số nào khác). Tuy nhiên, trong SPA, bạn sẽ cần tự xử lý bộ đệm ẩn (bằng cách sử dụng một số giải pháp như bộ đệm cấp hai, bộ đệm mẫu, v.v.).

Tôi muốn làm cho trường hợp của SPA là tốt nhất cho các ứng dụng hướng dữ liệu. gmail, tất nhiên là tất cả về dữ liệu và do đó là một ứng cử viên tốt cho một SPA.

Nhưng nếu trang của bạn chủ yếu để hiển thị, ví dụ: điều khoản của trang dịch vụ, thì một SPA hoàn toàn quá mức cần thiết.

Tôi nghĩ rằng điểm hấp dẫn là có một trang web có sự pha trộn của cả hai trang kiểu SPA và tĩnh / MVC, tùy thuộc vào trang cụ thể.

Ví dụ: trên một trang web tôi đang xây dựng, người dùng sẽ truy cập vào trang chỉ mục MVC tiêu chuẩn. Nhưng sau đó khi họ đi đến ứng dụng thực tế, thì nó gọi SPA. Một lợi thế khác là thời gian tải của SPA không phải trên trang chủ, mà trên trang ứng dụng. Thời gian tải trên trang chủ có thể là một sự phân tâm đối với người dùng trang web lần đầu tiên.

Kịch bản này hơi giống với việc sử dụng Flash. Sau một vài năm kinh nghiệm, số lượng trang web Flash chỉ giảm xuống gần bằng 0 do hệ số tải. Nhưng là một thành phần trang, nó vẫn được sử dụng.

Đối với các công ty như google, amazon, v.v., có máy chủ đang hoạt động với công suất tối đa ở chế độ 24/7, giảm lưu lượng có nghĩa là tiền thật - ít phần cứng, ít năng lượng hơn, ít bảo trì hơn. Việc chuyển đổi sử dụng CPU từ máy chủ sang máy khách sẽ được đền đáp và các SPA tỏa sáng. Những lợi thế thừa cân bất lợi cho đến nay. Vì vậy, SPA hay không SPA phụ thuộc nhiều vào trường hợp sử dụng.

Chỉ để đề cập đến một trường hợp sử dụng khác, có lẽ không quá rõ ràng (đối với các nhà phát triển Web) cho các SPA: Hiện tại tôi đang tìm cách triển khai GUI trong các hệ thống nhúng và kiến ​​trúc dựa trên trình duyệt có vẻ hấp dẫn đối với tôi. Theo truyền thống, không có nhiều khả năng cho các UI trong các hệ thống nhúng - các khung thương mại Java, Qt, wx, v.v. Vài năm trước Adobe đã cố gắng thâm nhập thị trường bằng đèn flash nhưng dường như không thành công lắm.

Ngày nay, vì "các hệ thống nhúng" mạnh như các máy tính lớn vài năm trước, một giao diện người dùng dựa trên trình duyệt được kết nối với thiết bị điều khiển thông qua REST là một giải pháp khả thi. Ưu điểm là, bảng công cụ khổng lồ cho UI miễn phí. (ví dụ: Qt yêu cầu 20-30 đô la cho mỗi đơn vị được bán với phí bản quyền cộng với 3000-4000 đô la cho mỗi nhà phát triển)

Đối với kiến ​​trúc như vậy, SPA cung cấp nhiều lợi thế - ví dụ như cách tiếp cận phát triển quen thuộc hơn cho các nhà phát triển ứng dụng máy tính để bàn, giảm quyền truy cập máy chủ (thường trong ngành công nghiệp xe hơi, các giao diện người dùng và hệ thống là phần cứng riêng biệt, trong đó phần hệ thống có HĐH RT).

Vì ứng dụng khách duy nhất là trình duyệt tích hợp, các nhược điểm được đề cập như tính khả dụng của JS, ghi nhật ký phía máy chủ, bảo mật không được tính nữa.

2. Với SPA, chúng tôi không cần sử dụng các truy vấn bổ sung vào máy chủ để tải xuống các trang.

Tôi vẫn phải học rất nhiều nhưng từ khi bắt đầu tìm hiểu về SPA, tôi yêu chúng.

Điểm đặc biệt này có thể tạo ra một sự khác biệt rất lớn.

Trong nhiều ứng dụng web không phải là SPA, bạn sẽ thấy rằng họ vẫn sẽ truy xuất và thêm nội dung vào các trang thực hiện yêu cầu ajax. Vì vậy, tôi nghĩ rằng SPA vượt xa bằng cách xem xét: điều gì xảy ra nếu nội dung sẽ được truy xuất và hiển thị bằng ajax là toàn bộ trang? và không chỉ là một phần nhỏ của một trang?

Hãy để tôi trình bày một kịch bản. Hãy xem xét rằng bạn có 2 trang:

1. một trang với danh sách các sản phẩm
2. một trang để xem chi tiết của một sản phẩm cụ thể

Hãy xem xét rằng bạn đang ở trang danh sách. Sau đó, bạn bấm vào một sản phẩm để xem chi tiết. Ứng dụng phía máy khách sẽ kích hoạt 2 yêu cầu ajax:

1. một yêu cầu để có được một đối tượng json với các chi tiết sản phẩm
2. yêu cầu lấy mẫu html trong đó chi tiết sản phẩm sẽ được chèn

Sau đó, ứng dụng phía máy khách sẽ chèn dữ liệu vào mẫu html và hiển thị nó.

Sau đó, bạn quay lại danh sách (không có yêu cầu nào được thực hiện cho việc này!) Và bạn mở một sản phẩm khác. Lần này, sẽ chỉ có một yêu cầu ajax để có được các chi tiết của sản phẩm. Mẫu html sẽ giống nhau vì vậy bạn không cần phải tải xuống lại.

Bạn có thể nói rằng trong một SPA không, khi bạn mở chi tiết sản phẩm, bạn chỉ thực hiện 1 yêu cầu và trong kịch bản này, chúng tôi đã làm 2. Có. Nhưng bạn có được lợi ích từ quan điểm tổng thể, khi bạn điều hướng qua nhiều trang, số lượng yêu cầu sẽ thấp hơn. Và dữ liệu được truyền giữa phía máy khách và máy chủ cũng sẽ thấp hơn vì các mẫu html sẽ được sử dụng lại. Ngoài ra, bạn không cần phải tải xuống trong mọi yêu cầu tất cả các tệp css, hình ảnh, javascript có trong tất cả các trang.

Ngoài ra, hãy xem xét rằng ngôn ngữ phía máy chủ của bạn là Java. Nếu bạn phân tích 2 yêu cầu mà tôi đã đề cập, 1 tải xuống dữ liệu (bạn không cần tải bất kỳ tệp xem nào và gọi công cụ hiển thị chế độ xem) và các bản tải xuống khác và mẫu html tĩnh để bạn có thể có máy chủ web HTTP có thể truy xuất nó trực tiếp mà không phải gọi máy chủ ứng dụng Java, không có tính toán nào được thực hiện!

Cuối cùng, các công ty lớn đang sử dụng SPA: Facebook, GMail, Amazon. Họ không chơi, họ có những kỹ sư vĩ đại nhất nghiên cứu tất cả những điều này. Vì vậy, nếu bạn không nhìn thấy những lợi thế ban đầu, bạn có thể tin tưởng chúng và hy vọng khám phá chúng.

Nhưng điều quan trọng là sử dụng các mẫu thiết kế SPA tốt. Bạn có thể sử dụng một khung như AngularJS. Đừng cố thực hiện một SPA mà không sử dụng các mẫu thiết kế tốt vì cuối cùng bạn có thể gặp rắc rối.

Nhược điểm : Về mặt kỹ thuật, thiết kế và phát triển ban đầu của SPA rất phức tạp và có thể tránh được. Các lý do khác để không sử dụng SPA này có thể là:

• a) Bảo mật: Ứng dụng Trang đơn kém an toàn hơn so với các trang truyền thống do tập lệnh chéo trang (XSS).
• b) Rò rỉ bộ nhớ: Rò rỉ bộ nhớ trong JavaScript thậm chí có thể khiến Máy tính mạnh bị chậm. Vì các trang web truyền thống khuyến khích điều hướng giữa các trang, do đó, bất kỳ rò rỉ bộ nhớ nào do trang trước gây ra gần như được xóa sạch để lại ít dư lượng phía sau.
• c) Máy khách phải kích hoạt JavaScript để chạy SPA, nhưng trong ứng dụng nhiều trang, JavaScript hoàn toàn có thể tránh được.
• d) SPA phát triển đến kích thước tối ưu, gây ra thời gian chờ đợi lâu. Ví dụ: Làm việc trên Gmail với kết nối chậm hơn.

Ngoài ra, các hạn chế về kiến ​​trúc khác là Mất dữ liệu điều hướng, Không có nhật ký Lịch sử điều hướng trong trình duyệt và khó khăn trong Kiểm tra chức năng tự động với selen.

Liên kết này giải thích các Ưu điểm và Nhược điểm của Ứng dụng Trang đơn.

Trong sự phát triển của mình, tôi đã tìm thấy hai lợi thế khác biệt khi sử dụng SPA. Điều đó không có nghĩa là không thể đạt được những điều sau đây trong một ứng dụng web truyền thống mà tôi thấy lợi ích gia tăng mà không đưa ra những bất lợi bổ sung.

• Tiềm năng cho yêu cầu máy chủ ít hơn vì hiển thị nội dung mới không phải luôn luôn hoặc thậm chí không bao giờ yêu cầu máy chủ http cho trang html mới. Nhưng tôi nói tiềm năng bởi vì nội dung mới có thể dễ dàng yêu cầu một cuộc gọi Ajax để lấy dữ liệu nhưng dữ liệu đó có thể nhẹ hơn so với chính nó cộng với đánh dấu mang lại lợi ích ròng.

• Khả năng duy trì trạng thái của nhà nước. Theo cách hiểu đơn giản nhất, hãy đặt một biến khi nhập vào ứng dụng và nó sẽ có sẵn cho các thành phần khác trong suốt trải nghiệm của người dùng mà không chuyển qua hoặc đặt nó vào mẫu lưu trữ cục bộ. Tuy nhiên, quản lý thông minh khả năng này là chìa khóa để giữ cho phạm vi cấp cao nhất không bị xáo trộn.

Ngoài việc yêu cầu JS (không phải là một điều điên rồ khi yêu cầu ứng dụng web), theo tôi, những nhược điểm đáng chú ý khác là không cụ thể đối với SPA hoặc có thể được giảm thiểu thông qua các thói quen tốt và mô hình phát triển.

Cố gắng không xem xét việc sử dụng SPA mà không xác định trước cách bạn sẽ giải quyết vấn đề bảo mật và ổn định API ở phía máy chủ. Sau đó, bạn sẽ thấy một số lợi thế thực sự khi sử dụng SPA. Cụ thể, nếu bạn sử dụng máy chủ RESTful thực hiện OAUTH 2.0 để bảo mật, bạn sẽ đạt được hai mối quan tâm cơ bản có thể làm giảm chi phí phát triển và bảo trì của bạn.

1. Điều này sẽ chuyển phiên (và đó là bảo mật) vào SPA và giải phóng máy chủ của bạn khỏi tất cả các chi phí đó.
2. API của bạn trở nên ổn định và dễ dàng mở rộng.

Gợi ý trước đó, nhưng không được làm rõ ràng; Nếu mục tiêu của bạn là triển khai các ứng dụng Android và Apple, viết một JavaScript SPA được bao bọc bởi một cuộc gọi riêng để lưu trữ màn hình trong trình duyệt (Android hoặc Apple) sẽ loại bỏ nhu cầu duy trì cả cơ sở mã Apple và cơ sở mã Android.

Tôi hiểu đây là một câu hỏi cũ hơn, nhưng tôi muốn thêm một nhược điểm khác của Ứng dụng Trang đơn:

Nếu bạn xây dựng API trả về kết quả bằng ngôn ngữ dữ liệu (như XML hoặc JSON) thay vì ngôn ngữ định dạng (như HTML), thì bạn đang cho phép khả năng tương tác ứng dụng lớn hơn, ví dụ, trong các ứng dụng từ doanh nghiệp đến doanh nghiệp (B2B). Khả năng tương tác như vậy có lợi ích lớn nhưng cho phép mọi người viết phần mềm để "khai thác" (hoặc đánh cắp) dữ liệu của bạn. Nhược điểm đặc biệt này là phổ biến đối với tất cả các API sử dụng ngôn ngữ dữ liệu và không nói chung với các SPA (thực sự, một SPA yêu cầu máy chủ cung cấp HTML được kết xuất trước để tránh điều này, nhưng phải trả giá cho việc tách mô hình / chế độ xem kém). Rủi ro này do nhược điểm này có thể được giảm thiểu bằng nhiều cách khác nhau, chẳng hạn như giới hạn yêu cầu và chặn kết nối, v.v.