Có phải là một ý tưởng tốt để làm UI 100% trong Javascript và cung cấp dữ liệu thông qua API không?

Công việc hàng ngày của tôi là làm các ứng dụng HTML. Với ý nghĩa đó, tôi có nghĩa là các ứng dụng loại CRUD được sử dụng nội bộ với rất nhiều khung lưới, hộp văn bản, danh sách thả xuống, v.v. Chúng tôi hiện đang sử dụng các biểu mẫu web ASP.NET, đã hoàn thành công việc, nhưng hiệu suất chủ yếu là ảm đạm phải nhảy qua vòng để có được thứ bạn cần Hoops được treo từ trần nhà và đốt cháy.

Vì vậy, tôi tự hỏi liệu có lẽ nên chuyển tất cả giao diện người dùng sang phía JavaScript. Phát triển một tập hợp các điều khiển có thể sử dụng lại được thiết kế riêng cho nhu cầu của chúng tôi và chỉ trao đổi dữ liệu với máy chủ. Có, tôi thích mô hình "điều khiển" (hay còn gọi là "widget"), nó khá phù hợp với các ứng dụng như vậy. Vì vậy, về phía máy chủ, chúng tôi vẫn sẽ có một mô phỏng bố cục cơ bản cho đánh dấu ASPX hiện tại của chúng tôi, nhưng sau đó sẽ chỉ được gửi đến máy khách một lần và phần Javascript sẽ xử lý tất cả các cập nhật UI tiếp theo.

Vấn đề là tôi chưa bao giờ làm điều này trước đây và tôi cũng chưa từng thấy ai làm điều này, vì vậy tôi không biết vấn đề sẽ là gì. Đặc biệt, tôi lo lắng về:

• Hiệu suất vẫn còn. Điểm chuẩn cho thấy hiện tại độ trễ chính nằm ở phía máy khách, khi trình duyệt cố gắng kết xuất lại hầu hết trang sau khi cập nhật AJAX. Các biểu mẫu web ASP.NET được tạo đánh dấu mang một ý nghĩa mới cho từ "web" và các điều khiển Deve े phong phú thêm lớp phức tạp Javascript của riêng chúng lên trên đó. Nhưng nó sẽ nhanh hơn để tính toán lại tất cả các thay đổi cần thiết ở phía Javascript và sau đó chỉ cập nhật những gì cần cập nhật? Lưu ý rằng tôi đang nói về các biểu mẫu có một số chế độ xem lưới có thể chỉnh sửa, nhiều hộp văn bản, nhiều danh sách thả xuống với các mục có thể lọc được nửa triệu, v.v.
• Dễ phát triển . Bây giờ sẽ có nhiều Javascript hơn và có lẽ nó sẽ trộn với đánh dấu HTML của trang. Đó hoặc một số loại công cụ xem mới sẽ phải được sản xuất. Intellisense cho Javascript cũng tệ hơn rất nhiều so với mã C # và do tính chất động của Javascript, nó không thể được mong đợi sẽ tốt hơn nhiều. Thực hành mã hóa có thể cải thiện nó một chút, nhưng không nhiều. Ngoài ra, hầu hết các nhà phát triển của chúng tôi chủ yếu là các nhà phát triển C # nên sẽ có một số lỗi học tập và sai lầm ban đầu.
• An ninh . Rất nhiều kiểm tra bảo mật sẽ phải được thực hiện hai lần (phía máy chủ và phía UI) và phía máy chủ xử lý dữ liệu sẽ phải bao gồm nhiều hơn nữa. Hiện tại, nếu bạn đặt hộp văn bản ở chế độ chỉ đọc ở phía máy chủ, bạn có thể phụ thuộc vào giá trị của nó không thay đổi thông qua roundtrip của máy khách. Khung đã có đủ mã để đảm bảo rằng (thông qua mã hóa viewstate). Với cách tiếp cận chỉ có dữ liệu, sẽ khó hơn vì bạn phải tự kiểm tra mọi thứ. Mặt khác, có thể lỗ hổng bảo mật sẽ dễ dàng phát hiện hơn, bởi vì bạn sẽ chỉ có dữ liệu để lo lắng.

Tất cả trong tất cả, điều này sẽ giải quyết vấn đề của chúng tôi, hoặc làm cho chúng tồi tệ hơn? Có ai đã từng thử điều này chưa, và kết quả là gì? Có bất kỳ khuôn khổ nào ngoài đó giúp đỡ trong nỗ lực này (jQuery và tương đương đạo đức sang một bên) không?

Linkedin làm điều này cho trang web di động của họ (xem http://engineering.linkedin.com/nodejs/blazed-fast-nodejs-10-performance-tips-linkedin-mobile phần 4) và rõ ràng nó rất có lợi cho họ từ một quan điểm hiệu suất.

Tuy nhiên, tôi khuyên bạn nên tránh làm như vậy, vì nhiều lý do.

Đầu tiên là khả năng bảo trì: C # / ASP.net, do nó là khung công tác phía máy chủ, không phụ thuộc vào máy khách, trong khi Javascript thì không (ngay cả với một khung như jQuery bạn sẽ không tương thích với trình duyệt chéo 100% , không chứng minh trong tương lai). Tôi muốn nói rằng việc xác minh chức năng của một ứng dụng được nhập tĩnh dễ dàng hơn so với ứng dụng động, đây là điều bạn hoàn toàn phải xem xét nếu bạn đang xây dựng các trang web quy mô lớn.

Thứ hai là bạn sẽ khó tìm được những người khác có khả năng (và sẵn sàng) xây dựng một ứng dụng javascript thuần túy về mức độ phức tạp cần thiết để chạy toàn bộ trang web của bạn (so với mức độ dễ tìm kiếm tương đối. Lập trình viên NET). Điều này có thể không phải là mối quan tâm của bạn trực tiếp, nhưng chắc chắn đó là điều cần suy nghĩ từ góc độ dài hạn.

Vấn đề thứ ba là khả năng tương thích của khách hàng; nếu bạn đang xây dựng các trang web công khai thì hãy nhớ rằng một phần hợp lý của mạng vẫn không được bật JS (vì nhiều lý do), vì vậy bạn cần chắc chắn rằng bạn sẽ không loại trừ một phần lớn của cơ sở người dùng của bạn bằng cách chuyển sang một trang web hướng đến JS.

Đối với mối quan tâm của bạn:

• Tôi sẽ không lo lắng quá nhiều về khía cạnh bảo mật, không có lý do gì bạn không thể trộn lẫn các mô hình và thực hiện một số xử lý phía máy chủ khi bạn yêu cầu bảo mật (bạn sẽ có một số mã hiển thị chế độ xem ở đâu đó trả về HTML , không có lý do gì bạn không thể thực hiện điều này chỉ bằng cách thực hiện cuộc gọi AJAX, khi được yêu cầu).

• Dễ phát triển không thực sự là một vấn đề quá quan trọng, theo tôi, có những công cụ rất tốt có sẵn để phát triển JS, đừng tự đóng hộp vào VisualStudio vì bạn đã quen với nó! (ví dụ dùng thử JetBrains WebStorm).

• Hiệu suất của các công cụ xem JS hoàn toàn tốt trong hầu hết các trường hợp (một lần nữa, theo kinh nghiệm của tôi), tôi sử dụng chúng rất nhiều trên cơ sở hàng ngày. Những gì tôi muốn đề xuất là tránh các khung nặng hơn như knout.js, v.v., và thay vào đó là một cái gì đó như công cụ mẫu vi mô của Jon Resig. Bằng cách này, bạn có thể cắm mã hỗ trợ theo cách bạn tự tin là nhanh và đáng tin cậy.

Những gì tôi sẽ làm, nếu tôi là bạn, thực sự kiểm tra lý do đằng sau việc chuyển đổi này; Cũng có thể là bạn không tận dụng .NET hiệu quả và cần nâng cấp trò chơi của mình, WebForms không phải là một khung công tác đặc biệt chậm, vì vậy có lẽ một số thư viện của bên thứ 3 bạn đang sử dụng đang làm chậm kết xuất của bạn.

Hãy thử thực hiện một hồ sơ hiệu năng của ứng dụng bằng cách sử dụng công cụ kiểm tra và định hình tải, và xem các điểm nghẽn của bạn ở đâu trước khi bạn chìm một lượng lớn thời gian và nỗ lực vào một giải pháp triệt để hơn, có lẽ bạn sẽ ngạc nhiên về những gì bạn tìm thấy thủ phạm cho sự chậm chạp của bạn!

Sử dụng ExtJS nếu bạn muốn đi theo cách đó, không phát minh lại bánh xe. Nhưng hãy chuẩn bị, điều này có nghĩa là một sự thay đổi mô hình hoàn chỉnh. Các kỹ năng HTML của bạn gần như lỗi thời. AJAX ở mọi nơi, máy chủ chủ yếu cung cấp API AJAX. Bạn sẽ viết nhiều javascript hơn bao giờ hết, vì vậy tốt hơn hãy chắc chắn rằng bạn thực sự phù hợp với javascript.

Nhóm tôi đã quyết định chuyển sang ExtJS vào cuối năm 2008. Chúng tôi đã có một ứng dụng PHP 200.000 dòng gặp sự cố ở mặt trước. Tình hình của chúng tôi tồi tệ hơn nhiều so với bạn, bởi vì chúng tôi có khung kiểm soát biểu mẫu được điều khiển bằng tay rất tệ và chúng tôi đã sử dụng rất nhiều iframe để tải các phần của trang (kiến trúc hình ảnh có từ năm 2005 và nhóm đã nhận thức được của ajax mà sớm về). Chúng tôi đã phải cấu trúc lại mã bằng mọi cách, vì vậy điều này giúp dễ dàng hơn trong việc quyết định nghiên cứu lại cơ sở mã chủ yếu ở phía khách hàng.

Ngày nay, ứng dụng này có 300.000 dòng, trong đó 60.000 dòng là mã extjs và khoảng 3/4 chức năng đã được chuyển sang ExtJS. Mã extjs là tất cả một ứng dụng một trang, nhưng nó vẫn nhúng một số hình thức kế thừa bên trong iframe. Chúng tôi đã chuyển qua container điều hướng trước, và sau đó di chuyển các khu vực tính năng khác nhau từng phần. Với cách tiếp cận này, chúng tôi đã xoay xở để di chuyển extjs vào quy trình phát triển tính năng thông thường, mà không làm chúng tôi chậm lại quá nhiều.

• Hiệu suất

  Mã ExtJS đã chứng minh nhanh hơn nhiều so với mã kế thừa. Mã cũ là hiệu suất thực sự tồi, nhưng ngay cả như vậy chúng tôi hài lòng với kết quả. Mã UI là tất cả các javascript tĩnh, vì vậy nó lưu trữ rất tốt (chúng tôi đang trong giai đoạn lập kế hoạch ném nó vào CDN). Máy chủ không tham gia vào kết xuất mặt trước, làm giảm khối lượng công việc ở đó. Nó cũng giúp ExtJS cung cấp nhiều quyền kiểm soát vòng đời của UI (kết xuất lười biếng, dễ dàng tải các phần tử UI vô hình). Thông thường một khi mã được bootstrapping (kiến trúc tải theo yêu cầu), phần lớn thời gian tải của màn hình được dành cho cuộc gọi dịch vụ web để lấy dữ liệu. Lưới ExtJS thực sự rất nhanh, đặc biệt là khi sử dụng các chế độ xem được đệm để hiển thị các hàng hiển thị khi cuộn.

• Dễ phát triển

  Thành thật mà nói, đây là một túi hỗn hợp. ExtJS là một DSL, nó không thực sự phát triển web theo nghĩa truyền thống. Phải mất nhiều thời gian để các nhà phát triển của chúng tôi thực sự tìm hiểu API của khung công tác và tôi không thấy đường cong này có độ dốc thấp hơn đối với các khung công tác phía khách hàng khác. Mọi người trong nhóm phải là nhà phát triển javascript "cao cấp" (theo nguyên tắc thông thường, cuốn sách của crockford không được giữ bí mật). Chúng tôi gặp phải vấn đề bootstrapping với các nhà phát triển mới, bởi vì chuyên môn về phía khách hàng không phổ biến như bạn nghĩ, và chuyên môn của extjs gần như không có (ở Bỉ, nơi chúng tôi đặt).

  Mặt khác, một khi bạn đã tăng tốc, trải nghiệm dev rất tuyệt vời. ExtJS rất mạnh, vì vậy nếu bạn ở trong rãnh, bạn có thể nhanh chóng lấy ra những màn hình tuyệt vời. IDE-khôn ngoan, chúng tôi sử dụng PHPStorm, mà tôi thấy đủ khả năng với mã ExtJS.

• Bảo vệ

  Bảo mật là một trong những lý do chính để thực hiện UI phía máy khách. Lý do rất đơn giản: tấn công giảm bề mặt. API dịch vụ web được sử dụng bởi mã ExtJS của chúng tôi có bề mặt tấn công nhỏ hơn nhiều so với lớp UI phía máy chủ. ASVS của OWASP chỉ định rằng bạn nên xác thực tất cả các đầu vào trên máy chủ cho chính xác trước khi sử dụng nó. Trong kiến ​​trúc dịch vụ web, rõ ràng và dễ dàng khi nào và làm thế nào để xác thực đầu vào. Tôi cũng thấy dễ dàng hơn để lý giải về bảo mật trong kiến ​​trúc UI phía máy khách. Chúng tôi vẫn phải vật lộn với các vấn đề XSS, vì bạn không được miễn trừ mã hóa sang HTML, nhưng nhìn chung chúng tôi bảo mật tốt hơn nhiều so với trên cơ sở mã cũ. ExtJS giúp dễ dàng thực hiện xác thực phía máy chủ của các trường biểu mẫu, vì vậy chúng tôi không phải chịu đựng nhiều khi phải viết mã hai lần.

Nếu bạn có thể đủ khả năng để không hỗ trợ người dùng không có tập lệnh và các công cụ tìm kiếm không liên quan đến bạn, thì có, đó là một cách tiếp cận hoàn toàn khả thi. Dưới đây là một bản tóm tắt ngắn gọn về những ưu và nhược điểm:

Ưu điểm:

• mọi thứ ở một nơi (javascript)
• bạn có thể tải dữ liệu từ máy chủ, không đánh dấu, có thể tiết kiệm rất nhiều băng thông nếu được thực hiện đúng
• dễ dàng hơn để có được một ứng dụng đáp ứng (độ trễ mạng vẫn còn, nhưng phản hồi ban đầu đối với đầu vào của người dùng đến nhanh hơn)
• máy chủ web không cần kết xuất bất kỳ HTML nào hoặc mở rộng bất kỳ mẫu nào (nghĩa là, nỗ lực xử lý được chuyển từ máy chủ sang máy khách)

Nhược điểm:

• mọi thứ cần phải có trong javascript (có thể có hoặc không có vấn đề)
• logic quan trọng cần được nhân đôi trên máy chủ
• trạng thái cần được duy trì trên máy khách và máy chủ và được đồng bộ hóa giữa cả hai
• bảo mật có thể khó hơn để có được quyền (xem xét cách mọi thứ trong mã phía máy khách có thể bị thao túng bởi người dùng độc hại)
• bạn để lộ một phần lớn cơ sở mã của bạn (mã chạy trên máy chủ không thể nhìn thấy từ bên ngoài)

Cá nhân, tôi nghĩ rằng nếu bạn đi theo con đường này, ASP.NET UpdatePanels không phải là con đường đúng đắn. Chúng rất tuyệt vời khi làm sáng tỏ một phần các ứng dụng web hiện có, nhưng chúng vẫn gửi HTML qua AJAX và quản lý trạng thái theo cách này có thể rất nhiều lông. Tốt hơn hết là bạn nên sử dụng một tài liệu HTML tĩnh và sau đó sử dụng thư viện mẫu javascript để thực hiện kết xuất HTML; máy chủ hoàn toàn không phục vụ bất kỳ HTML động nào, thay vào đó, máy khách thực hiện các cuộc gọi mức logic nghiệp vụ vào máy chủ và nhận dữ liệu thô.

Có bạn có thể nhưng ..

Bạn cần đảm bảo rằng bạn đã "xuống cấp" duyên dáng để các phần quan trọng trong ứng dụng của bạn sẽ vẫn hoạt động mà không cần Javascript.

Đây là cách tôi xây dựng hầu hết các ứng dụng theo kiểu "HIJAX".

Trang web của tôi vẫn còn trong giai đoạn trứng nước nhưng 100% js ui vẫn ổn đối với tôi cho đến nay. Logic máy chủ duy nhất tồn tại ở mặt trước là ánh xạ mô hình và các url ajax. Máy chủ không có kiến ​​thức về ui, điều này với tôi rất dễ bảo trì. Nếu bạn quan tâm, bạn có thể kiểm tra trang web của tôi được viết bằng ExtJS http://coffeedig.com/coffee/ . Trang web của tôi không thực sự có bất kỳ vấn đề bảo mật nào nhưng khách hàng sẽ giúp người dùng bình thường bằng cách xác thực đơn giản. Tôi biết rằng một người dùng độc hại thực sự có thể gửi bất kỳ ajax nào đến máy chủ để tất cả logic "bảo mật" được thực hiện trên máy chủ.

Tôi nghĩ vấn đề lớn nhất đối với bạn là bạn sẽ hoàn toàn đảo ngược những gì nhóm của bạn đã quen, sẽ có một đường cong học tập dốc. Tôi nghĩ cách tiếp cận tốt nhất sẽ là thử nghiệm với một số khung js và cố gắng cảm nhận nó bằng cách viết một số màn hình đơn giản.