Sử dụng một khung như Backbone [đã đóng]

Tôi hiện có một trang http://proctors.org/tv được điều khiển bởi một số lượt xem và tệp đính kèm với hàng tấn jQuery và spaghetti JavaScript được hack cùng nhau, và tôi muốn làm sạch nó. Tôi hiểu rằng các khung "MVC" Javascript mới hơn sử dụng các mẫu và không lưu trữ nghiêm ngặt tất cả dữ liệu trong DOM như bạn có thể làm với jQuery.

Tôi tin rằng bạn sẽ sử dụng một cái gì đó như Dịch vụ và / hoặc Lượt xem làm phụ trợ, với Backbone ở phía trước.

Có một dự án Do cho xương sống và tôi nhớ rằng có một BoF hoặc Phiên tại DrupalCon Denver về nó ...

Tôi hy vọng khám phá liệu có đáng để tôi dành thời gian để thử và viết lại điều này trong một khuôn khổ mới hay chỉ cần làm sạch những gì tôi có ở đây.

Tôi đã sử dụng cả Ember và Backbone cùng với Drupal - nhưng không phải theo cách bạn nghĩ.

Ember và Backbone đều là những công cụ tốt để tạo một ứng dụng web - nhưng Drupal không thực sự là một công cụ tốt để sử dụng cùng với chúng. Những gì bạn mong muốn khi bạn xây dựng một ứng dụng web là một cái gì đó nhẹ và nhanh. Bạn muốn nó nhanh để có thể mang lại cho người dùng cảm giác nếu thời gian phản hồi ngay lập tức. Bạn muốn nó nhẹ để làm cho nó có quy mô tốt hơn. Drupal không nhanh - bootstrap đầy đủ của Drupal mất nhiều thời gian (so với rất nhiều tùy chọn khác) nếu tất cả những gì bạn muốn làm là cung cấp API REST cho ứng dụng web của bạn. Drupal là PHP, điều này cũng khiến RAM khá đói, hạn chế số lượng người dùng đồng thời.

Vì vậy, nếu Drupal rất tệ cho việc này tại sao lại sử dụng nó?

Bạn thực sự nên sử dụng Drupal cho những gì Drupal vượt trội - một CMS. Những gì tôi đã làm trong quá khứ với các dự án cần một ứng dụng web là sử dụng Drupal để tạo CMS xung quanh ứng dụng web. Để xây dựng những thứ như blog, danh sách nội dung và lượt thích. Tôi cũng đã tạo các mô-đun để định nghĩa một số nội dung phụ trợ - như định nghĩa lược đồ và các công cụ khác có ý nghĩa khi sử dụng Drupal - vì nó giúp cho việc phát triển của tôi dễ dàng hơn nhiều.

Thay vì sử dụng Drupal để tạo API REST mà ứng dụng web cần - tôi đã sử dụng Node.js để tạo API REST thực tế và kiểm tra các lệnh gọi AJAX khác mà ứng dụng web cần thực hiện. Node.js vượt trội khi làm việc này. Nó rất nhanh (thời gian phản hồi thấp tới 30ms cho một danh sách các đối tượng). Nó cũng rất nhẹ, vì JavaScript trên máy chủ sử dụng các hành động không đồng bộ, máy chủ Node.js thường có thể xử lý hàng ngàn người dùng đồng thời trong đó PHP có thể xử lý có thể 100. Ngoài ra - vì Node.js là JavaScript, bạn có thể sử dụng lại rất nhiều của máy chủ mã và phía máy khách. Theo nghĩa đen, bạn có thể viết cùng một mã xác thực, thay vì phải triển khai cả phía máy khách trong JavaScript và phía máy chủ trong PHP. Nếu bạn sẽ đến Drupal con ở Münich trong một vài tuần - bạn nên xem xét việc trình bày node.js.

Vì vậy, nếu bạn là một nhà phát triển, tôi thực sự khuyên bạn nên thực hiện một thiết lập tương tự và chỉ sử dụng Drupal cho những gì nó thực sự tốt. Nếu bạn muốn tạo một ứng dụng web đơn giản và bạn không mong đợi nhiều người dùng, sử dụng Drupal làm phụ trợ có thể là một lựa chọn nếu nó giúp ích cho thời gian phát triển của bạn.

Cập nhật Drupal 8

Vì vậy, với việc phát hành Drupal 8, một số điều trên vẫn đúng nhưng không được gia hạn như trước. Drupal 8 giống như Drupal 7 không phải là một công cụ nhẹ, như Node.js, Rails, Django, v.v. Vì các ứng dụng JavaScript chủ yếu sử dụng các dịch vụ khác nhau, bạn vẫn nên xem xét liệu Drupal có phải là công cụ tốt nhất cho việc này không.

Với Drupal 8, rất nhiều thứ đã được cải thiện. Dịch vụ là bản địa hơn rất nhiều, với Symphony điều khiển yêu cầu / phản hồi. Drupal 8 có rất nhiều khả năng thú vị với bộ nhớ đệm nâng cao và tất cả các tính năng tuyệt vời. Nhưng ngay cả với tất cả sự tuyệt vời của Drupal 8, nó vẫn nặng hơn rất nhiều so với các ứng dụng trọng lượng nhẹ. Thật khó để nói Drupal 8 có thể được sử dụng như một nhà cung cấp dịch vụ web nhanh như thế nào.

Tuy nhiên, với tất cả những gì đã nói và thực hiện, khuyến nghị chung của tôi vẫn giữ nguyên. Là một nhà phát triển Drupal, thật dễ dàng để sử dụng Drupal cho mọi thứ, vì chúng ta đã quen với nó. Nó cảm thấy an toàn và Drupal có thể được sử dụng cho bất cứ điều gì. Hãy nhớ rằng trong khi có thể sử dụng Drupal cho bất cứ điều gì, điều đó không có nghĩa đó là công cụ tốt nhất cho mọi thứ. Thực hiện phân tích âm thanh và hiểu được điểm mạnh và điểm yếu của các công cụ bạn muốn sử dụng trong dự án CNTT, sẽ luôn giúp ích rất nhiều và có thể giúp bạn tránh kết thúc ở vị trí bế tắc với kết quả không như mong đợi của bạn .

Gần đây tôi đã bắt đầu phát triển ứng dụng xương sống + drupal đầu tiên của mình và tôi thực sự thích nó. Sử dụng mô-đun xương sống cùng với Dịch vụ, Chế độ xem dịch vụ và các thư viện cần thiết. Dự án khá đơn giản: Để tạo một băng chuyền có thể quản lý nội dung gồm 6 trang hiển thị nhiều dữ liệu khác nhau, cùng với một thanh trượt Tin tức bổ sung hiển thị nội dung khác nhau. Trang này nằm trên nhiều màn hình khác nhau mà không có sự tương tác của người dùng, do đó yêu cầu khả năng cập nhật nội dung giao diện người dùng mà không cần làm mới trình duyệt. Tôi nghĩ rằng điều này hoàn toàn phù hợp với ứng dụng Drupal + Backbone với Drupal quản lý nội dung và kiểm soát xương sống và đồng bộ hóa với db. Tôi đã tích hợp trong jquery. Motorcycle 2 có API tuyệt vời và phù hợp với phong cách mã hóa MVC.

Tôi có thể thấy lý do tại sao mọi người có thể bịt mũi khi sử dụng Drupal làm khung phụ trợ nhưng đối với một ứng dụng nhỏ như Drupal này thì nhẹ và nhanh . Tôi đã đạt được điều này bằng cách bắt đầu với một cài đặt tối thiểu và cẩn thận chọn các mô-đun đóng góp và cốt lõi. Bây giờ tôi đang ở khoảng 50 mô-đun với chỉ dưới 150 dòng mã JS tùy chỉnh cho các công cụ xương sống và tôi đã hoàn thành khá nhiều việc.

Cuối cùng, tôi sẽ cố gắng cam kết điều này trở lại làm ví dụ cho mô đun xương sống vì hiện tại không có ví dụ nào cho thấy cách sử dụng Chế độ xem làm bộ sưu tập, v.v.

Cuối cùng:

Rất đáng để bạn dành thời gian để xem xét điều này nếu dự án của bạn phù hợp. Theo tôi, các vấn đề về hiệu năng xuất phát từ sự nặng nề của Drupal có thể dễ dàng được giải quyết bằng cách sử dụng các cơ chế lưu trữ như Varnish, hoặc thậm chí tăng cường hoặc bộ đệm trang lõi. Tính linh hoạt và tốc độ phát triển từ việc sử dụng Drupal hoàn toàn vượt xa những tiêu cực đối với tôi.

Câu trả lời cơ bản là có, một số người đang sử dụng nó. Bản thân tôi chưa sử dụng nó (chưa tìm thấy một dự án phù hợp nào), nhưng hiện tại có một nhóm Drupal cho nó và nó cũng phù hợp với Dịch vụ web và Sáng kiến ​​bối cảnh cốt lõi , một trong những Sáng kiến ​​8 của Drupal . Ngoài ra còn có một phiên tại DrupalCon Munich 2012, Backbone.js trong Frontend .

Tôi không biết liệu nó đã sẵn sàng cho thời gian chính chưa, nhưng theo tôi, đáng để tạo ra một bằng chứng về khái niệm nếu bạn có thứ gì đó có thể có lợi từ nó và có thể thiết kế bên JS thành giao diện chứ không phải triển khai . Điều đó sẽ giúp cách ly mọi thay đổi phụ trợ nếu bạn quyết định bảo lãnh cho Drupal, vì bất kỳ lý do gì.

Bạn có thể thấy điều này hữu ích: nó cho thấy một ví dụ về việc chuyển đổi tập lệnh dựa trên JQuery thành tập lệnh xương sống. Rõ ràng là bạn sẽ cần phải sử dụng backbone.js, dưới dạng thư viện bằng drupal_add_js hoặc sử dụng mô-đun.

https://github.com/kjbekkelund/writings/blob/master/published/under Hiểu-backbone.md /