Tôi sắp tạo ra một loạt các ứng dụng web từ đầu. (Xem http://50pop.com/code để biết tổng quan.) Tôi muốn họ có thể được truy cập từ nhiều khách hàng khác nhau: trang web mặt trước, ứng dụng điện thoại thông minh, dịch vụ web phụ trợ, v.v. Vì vậy, tôi thực sự muốn một API REST REST cho mỗi cái.

Ngoài ra, tôi thích làm việc ở mặt sau, vì vậy tôi mơ mộng về việc tôi tập trung hoàn toàn vào API và thuê người khác tạo giao diện người dùng, cho dù là trang web, iPhone, Android hoặc ứng dụng khác.

Xin hãy giúp tôi quyết định cách tiếp cận nào tôi nên thực hiện:

CÔ GÁI Ở RAILS

Tạo một ứng dụng web Rails rất chuẩn. Trong bộ điều khiển, thực hiện chuyển đổi answer_with, để phục vụ JSON hoặc HTML. Phản hồi JSON là API của tôi.

Pro: Rất nhiều tiền lệ. Tiêu chuẩn tuyệt vời và nhiều ví dụ về làm mọi thứ theo cách này.

Con: Không nhất thiết muốn API giống như ứng dụng web. Không thích if / then answer_with với cách tiếp cận chuyển đổi. Trộn hai thứ rất khác nhau (UI + API).

REST SERVER + KHÁCH HÀNG JAVASCRIPT-HEAVY

Tạo một máy chủ API REST chỉ JSON. Sử dụng Backbone hoặc Ember.js cho JavaScript phía máy khách để truy cập API trực tiếp, hiển thị các mẫu trong trình duyệt.

Pro: Tôi thích sự tách biệt của API & client. Người thông minh nói rằng đây là con đường để đi. Tuyệt vời trong lý thuyết. Có vẻ tiên tiến và thú vị.

Con: Không có nhiều tiền lệ. Không có nhiều ví dụ về điều này được thực hiện tốt. Các ví dụ công khai (twitter.com) cảm thấy chậm chạp & thậm chí đang chuyển hướng khỏi phương pháp này.

REST SERVER + CLIENT HTML CLIENT

Tạo một máy chủ API REST chỉ JSON. Tạo một ứng dụng khách trang web HTML cơ bản, chỉ truy cập API REST. JavaScript phía máy khách ít hơn.

Pro: Tôi thích sự tách biệt của API & client. Nhưng việc phục vụ HTML5 đơn giản là khá dễ dàng và không cần nhiều khách hàng.

Con: Không có nhiều tiền lệ. Không có nhiều ví dụ về điều này được thực hiện tốt. Các khung không hỗ trợ điều này là tốt. Không chắc làm thế nào để tiếp cận nó.

Đặc biệt là tìm kiếm lời khuyên từ kinh nghiệm, không chỉ trong lý thuyết.

Tại Boundless , chúng tôi đã đi sâu với lựa chọn số 2 và tung ra cho hàng ngàn sinh viên. Máy chủ của chúng tôi là API JSON REST (Scala + MongoDB) và tất cả mã khách hàng của chúng tôi được cung cấp trực tiếp từ CloudFront (ví dụ: www.boundless.com chỉ là bí danh cho CloudFront).

Ưu điểm:

• Tiên tiến / thú vị
• Rất nhiều lợi ích cho bạn: API cung cấp cho bạn cơ sở cho máy khách web của riêng bạn, máy khách di động, quyền truy cập của bên thứ 3, v.v.
• quá trình tải trang / chuyển trang cực kỳ nhanh

Nhược điểm:

• Không thân thiện với SEO / sẵn sàng mà không cần làm việc nhiều.
• Yêu cầu dân gian đầu trang web hàng đầu, những người sẵn sàng đối phó với thực tế của trải nghiệm trang web là 70% javascript và điều đó có nghĩa là gì.

Tôi nghĩ rằng đây là tương lai của tất cả các ứng dụng web.

Một số suy nghĩ cho những người ở phía trước web (đó là nơi mà tất cả các thử thách / thử thách mới được đưa ra cho kiến ​​trúc này):

• CoffeeScript. Dễ dàng hơn nhiều để sản xuất mã chất lượng cao.
• Xương sống. Cách tuyệt vời để tổ chức logic của bạn và cộng đồng tích cực.
• HAMLC. Các mẫu Haml + CoffeeScript => JS.
• SASS

Chúng tôi đã xây dựng một khai thác cho sự phát triển mặt trước của chúng tôi được gọi là 'Spar' (Tên lửa ứng dụng trang đơn), đây thực sự là đường dẫn tài sản từ Rails được điều chỉnh để phát triển ứng dụng một trang. Chúng tôi sẽ tìm nguồn mở trong vài tuần tới trên trang github của chúng tôi , cùng với một bài đăng trên blog giải thích cách sử dụng nó và kiến ​​trúc tổng thể chi tiết hơn.

CẬP NHẬT:

Đối với mối quan tâm của mọi người với Backbone, tôi nghĩ họ bị đánh giá quá cao. Xương sống là một nguyên tắc tổ chức hơn nhiều so với một khuôn khổ sâu sắc. Bản thân trang web của Twitter là một con quái vật khổng lồ của Javascript bao trùm mọi trường hợp góc trên hàng triệu người dùng và trình duyệt cũ, trong khi tải các tweet theo thời gian thực, thu gom rác, hiển thị nhiều phương tiện đa phương tiện, v.v. thấy, Twitter là một trong những lẻ. Đã có nhiều ứng dụng phức tạp ấn tượng được phân phối thông qua JS mà giá vé rất tốt.

Và sự lựa chọn của bạn về kiến ​​trúc phụ thuộc hoàn toàn vào mục tiêu của bạn. Nếu bạn đang tìm kiếm cách nhanh nhất để hỗ trợ nhiều khách hàng và có quyền truy cập vào tài năng giỏi, thì đầu tư vào API độc lập là một cách tuyệt vời.

Rất tốt hỏi. +1. Chắc chắn, đây là tài liệu tham khảo hữu ích trong tương lai cho tôi. Ngoài ra @Aaron và những người khác đã thêm giá trị để thảo luận. Giống như Ruby, câu hỏi này cũng có thể áp dụng cho các môi trường lập trình khác.

Tôi đã sử dụng hai tùy chọn đầu tiên. Cái đầu tiên cho nhiều ứng dụng và cái thứ hai cho dự án nguồn mở Cowoop của tôi

lựa chọn 1

Điều này không nghi ngờ gì là phổ biến nhất. Nhưng tôi thấy việc thực hiện rất nhiều http-ish. Mỗi mã ban đầu của API đều xử lý đối tượng yêu cầu. Vì vậy, mã API không chỉ là ruby ​​/ python / mã ngôn ngữ khác.

Lựa chọn 2

Tôi luôn luôn yêu thích điều này.

Tùy chọn này cũng ngụ ý rằng HTML không phải là thời gian chạy được tạo trên máy chủ. Đây là cách tùy chọn 2 khác với tùy chọn 3. Nhưng được xây dựng dưới dạng html tĩnh bằng cách sử dụng tập lệnh xây dựng. Khi được tải về phía máy khách, các HTML này sẽ gọi máy chủ API là máy khách API API.

• Tách biệt mối quan tâm là lợi thế lớn. Và rất nhiều theo ý thích của bạn (và của tôi) các chuyên gia phụ trợ triển khai API phụ trợ, kiểm tra chúng dễ dàng như mã ngôn ngữ thông thường mà không phải lo lắng về mã yêu cầu khung / http.

• Điều này thực sự không khó như âm thanh ở phía trước. Các lệnh gọi API và dữ liệu kết quả (chủ yếu là json) có sẵn cho mẫu phía máy khách hoặc MVC của bạn.

• Ít xử lý phía máy chủ. Nó có nghĩa là bạn có thể đi cho phần cứng hàng hóa / máy chủ ít tốn kém hơn.

• Dễ dàng hơn để kiểm tra các lớp độc lập, dễ dàng hơn để tạo tài liệu API.

Nó có một số nhược điểm.

• Nhiều nhà phát triển tìm thấy điều này qua thiết kế và khó hiểu. Vì vậy, rất có thể kiến ​​trúc có thể bị chỉ trích.

• i18n / l10n là khó. Vì HTML về cơ bản được tạo nên thời gian xây dựng là tĩnh, nên một người cần nhiều bản dựng cho mỗi ngôn ngữ được hỗ trợ (điều này không nhất thiết là điều xấu). Nhưng ngay cả với điều đó bạn có thể có các trường hợp góc khoảng l10n / i18n và cần phải cẩn thận.

Lựa chọn 3

Mã hóa cuối cùng trong trường hợp này phải giống như tùy chọn thứ hai. Hầu hết các điểm cho tùy chọn 2 cũng được áp dụng ở đây.

Các trang web được kết xuất thời gian chạy bằng cách sử dụng các mẫu phía máy chủ. Điều này làm cho i18n / l10n dễ dàng hơn nhiều với các kỹ thuật được thiết lập / chấp nhận hơn. Có thể là một cuộc gọi http ít hơn cho một số ngữ cảnh thiết yếu cần thiết để hiển thị trang như người dùng, ngôn ngữ, tiền tệ, v.v. Vì vậy, việc xử lý phía máy chủ được tăng lên với kết xuất nhưng có thể được bù bằng các cuộc gọi http đến máy chủ API ít hơn.

Bây giờ các trang là máy chủ được hiển thị trên máy chủ, frontend giờ gắn chặt hơn với môi trường lập trình. Điều này có thể thậm chí không được xem xét cho nhiều ứng dụng.

Trường hợp Twitter

Theo tôi hiểu, Twitter có thể thực hiện hiển thị trang ban đầu của họ trên máy chủ nhưng đối với các cập nhật trang, nó vẫn có một số lệnh gọi API và các mẫu phía máy khách để thao tác DOM. Vì vậy, trong trường hợp như vậy, bạn có các mẫu kép để duy trì thêm một số chi phí và độ phức tạp. Không phải ai cũng có thể mua tùy chọn này, không giống như Twitter.

Dự án của chúng tôi Stack

Tôi tình cờ sử dụng Python. Tôi sử dụng JsonRPC 2.0 thay vì REST. Tôi đề nghị REST, mặc dù tôi thích ý tưởng về JsonRPC vì nhiều lý do. Tôi sử dụng các thư viện dưới đây. Ai đó đang cân nhắc lựa chọn 2/3 có thể thấy nó hữu ích.

• API Server: Python Một khung vi mô web nhanh - Flask
• Máy chủ giao diện: Nginx
• MVC phía máy khách: Knockout.js
• Các công cụ / libs liên quan khác:
  • Jquery
  • Account.js cho tiền tệ
  • Webshim : Đa trình duyệt chéo
  • giám đốc : định tuyến phía khách hàng
  • sphc : thế hệ HTML

Kết luận và đề nghị của tôi

Lựa chọn 3!.

Tất cả đã nói, tôi đã sử dụng tùy chọn 2 thành công nhưng bây giờ nghiêng về tùy chọn 3 để đơn giản hơn. Tạo các trang HTML tĩnh với tập lệnh xây dựng và phục vụ chúng với một trong những máy chủ cực nhanh chuyên phục vụ các trang tĩnh rất hấp dẫn (Tùy chọn 2).

Chúng tôi đã chọn # 2 khi xây dựng gaug.es. Tôi đã làm việc về API (ruby, sinatra, v.v.) và đối tác kinh doanh của tôi, Steve Smith, đã làm việc trên front-end (ứng dụng javascript).

Ưu điểm:

1. Di chuyển nhanh song song. Nếu tôi làm việc trước Steve, tôi có thể tiếp tục tạo API cho các tính năng mới. Nếu anh ta làm việc trước tôi, anh ta có thể giả mạo API rất dễ dàng và xây dựng giao diện người dùng.

2. API miễn phí. Có quyền truy cập mở vào dữ liệu trong ứng dụng của bạn sẽ nhanh chóng trở thành một tính năng tiêu chuẩn. Nếu bạn bắt đầu với một API từ đầu, bạn sẽ nhận được nó miễn phí.

3. Sạch tách. Tốt hơn là nghĩ về ứng dụng của bạn như một API với khách hàng. Chắc chắn, ứng dụng khách đầu tiên và quan trọng nhất có thể là một trang web, nhưng nó giúp bạn dễ dàng tạo các ứng dụng khách khác (iPhone, Android).

Nhược điểm:

1. Tương thích ngược. Điều này liên quan nhiều đến API hơn là câu hỏi trực tiếp của bạn, nhưng một khi API của bạn ở ngoài đó, bạn không thể phá vỡ nó hoặc bạn phá vỡ tất cả hai khách hàng của mình. Điều này không có nghĩa là bạn phải di chuyển chậm hơn, nhưng điều đó có nghĩa là bạn phải thường xuyên làm hai việc cùng một lúc. Thêm vào API hoặc các trường mới là tốt, nhưng thay đổi / xóa không nên được thực hiện mà không cần phiên bản.

Tôi không thể nghĩ đến khuyết điểm nữa.

Kết luận: API + JS client là cách tốt nhất nếu bạn có kế hoạch phát hành API.

PS Tôi cũng sẽ khuyên bạn nên ghi lại đầy đủ tài liệu API của bạn trước khi phát hành nó. Quá trình ghi lại API Gaug.es thực sự đã giúp chúng tôi thúc đẩy

http://get.gaug.es/documentation/api/

Tôi thích đi theo con đường # 2 và # 3. Chủ yếu là vì # 1 vi phạm sự tách biệt các mối quan tâm và xen kẽ tất cả các loại công cụ. Cuối cùng, bạn sẽ thấy cần phải có điểm cuối API không có trang HTML phù hợp / v.v. và bạn sẽ trở thành một con suối với các điểm cuối HTML và JSON xen kẽ trong cùng một cơ sở mã. Nó biến thành một mớ hỗn độn kỳ quái, ngay cả khi MVP của nó, cuối cùng bạn sẽ phải viết lại nó bởi vì nó rất lộn xộn rằng nó thậm chí không đáng để cứu vãn.

Đi với # 2 hoặc # 3 cho phép bạn hoàn toàn có một API hoạt động giống nhau (đối với hầu hết các phần) bất kể. Điều này cung cấp sự linh hoạt tuyệt vời. Tôi chưa bán 100% trên Backbone / ember / anything / etcjs. Tôi nghĩ nó thật tuyệt, nhưng như chúng ta đang thấy với twitter thì điều này không tối ưu. NHƯNG ... Twitter cũng là một con thú khổng lồ của một công ty và có hàng trăm triệu người dùng. Vì vậy, bất kỳ cải tiến có thể có tác động rất lớn đến lợi nhuận trên các lĩnh vực khác nhau của các đơn vị kinh doanh khác nhau. Tôi nghĩ rằng có nhiều quyết định hơn là tốc độ một mình và họ không cho phép chúng tôi làm điều đó. Nhưng đó chỉ là ý kiến ​​của tôi. Tuy nhiên, tôi không giảm giá xương sống và các đối thủ cạnh tranh của nó. Các ứng dụng này rất tốt để sử dụng và rất sạch sẽ và rất nhạy (đối với hầu hết các phần).

Tùy chọn thứ ba cũng có một số sức hấp dẫn hợp lệ. Đây là nơi tôi tuân theo nguyên tắc Pareto (quy tắc 80/20) và có 20% đánh dấu chính của bạn (hoặc ngược lại) được hiển thị trên máy chủ và sau đó có một máy khách JS đẹp (xương sống / v.v.) chạy phần còn lại của nó . Bạn có thể không giao tiếp 100% với api REST thông qua ứng dụng khách JS, nhưng bạn sẽ thực hiện một số công việc nếu cần thiết để giúp trải nghiệm suer tốt hơn.

Tôi nghĩ rằng đây là một trong những vấn đề "nó phụ thuộc" và câu trả lời là "nó phụ thuộc" vào những gì bạn đang làm, những người bạn đang phục vụ và loại kinh nghiệm bạn muốn họ nhận được. Cho rằng tôi nghĩ bạn có thể quyết định giữa 2 hoặc 3 hoặc lai chúng.

Tôi hiện đang làm việc để chuyển đổi một CMS khổng lồ từ tùy chọn 1 sang tùy chọn 3 và nó sẽ hoạt động tốt. Chúng tôi đã chọn hiển thị phía máy chủ đánh dấu vì SEO là một vấn đề lớn đối với chúng tôi và chúng tôi muốn các trang web hoạt động tốt trên điện thoại di động.

Tôi đang sử dụng node.js cho back-end của khách hàng và một số mô-đun để giúp tôi. Tôi hơi sớm trong quá trình nhưng nền tảng đã được thiết lập và đó là vấn đề vượt qua dữ liệu để đảm bảo tất cả đều đúng. Đây là những gì tôi đang sử dụng:

• Thể hiện cho nền tảng của ứng dụng.
  (https://github.com/visionmedia/express)
• Yêu cầu lấy dữ liệu.
  (https://github.com/mikeal/request)
• Mẫu gạch dưới có được kết xuất phía máy chủ. Tôi sử dụng lại những thứ này trên máy khách.
  (https://github.com/documentcloud/underscore)
• UTML kết thúc các mẫu gạch dưới để làm cho chúng hoạt động với Express.
  (https://github.com/mikefrey/utml)
• Trả trước thu thập các mẫu và cho phép bạn chọn được gửi cho khách hàng.
  (https://github.com/mrDarcyMurphy/upfront)
• Express Expose chuyển dữ liệu được tìm nạp, một số mô-đun và mẫu vào giao diện người dùng.
  (https://github.com/visionmedia/express-expose)
• Xương sống tạo ra các mô hình và khung nhìn ở mặt trước sau khi nuốt dữ liệu được truyền qua.
  (https://github.com/documentcloud/backbone)

Đó là cốt lõi của ngăn xếp. Một số mô-đun khác tôi thấy hữu ích:

• fleck (https // github.com / trek / fleck)
• khoảnh khắc (https // github.com / timrwood / khoảnh khắc)
• bút stylus (https // github.com / LearnBoost / bút stylus)
• smoosh (https // github.com / fat / smoosh)
  mặc dù tôi đang tìm kiếm grunt (https // github.com / cowboy / grunt)
• theo dõi bảng điều khiển (//github.com/LearnBoost/console-trace).

Không, tôi không sử dụng cà phê.

Tùy chọn này đang làm việc thực sự tốt cho tôi. Các mô hình ở mặt sau không tồn tại vì dữ liệu chúng tôi nhận được từ API có cấu trúc tốt và tôi chuyển nó nguyên văn sang mặt trước. Ngoại lệ duy nhất là mô hình bố cục của chúng tôi nơi tôi thêm một thuộc tính duy nhất giúp hiển thị thông minh hơn và nhẹ hơn. Tôi đã không sử dụng bất kỳ thư viện mô hình ưa thích nào cho điều đó, chỉ là một chức năng bổ sung những gì tôi cần khi khởi tạo và trả về chính nó.

(xin lỗi vì các liên kết kỳ lạ, tôi quá nhiều n00b cho stack stack để cho phép tôi đăng nhiều như vậy)

Chúng tôi sử dụng biến thể sau của # 3: Tạo máy chủ API REST chỉ JSON. Tạo một máy chủ trang web HTML. Máy chủ web HTML không phải là máy khách của máy chủ API REST. Thay vào đó, hai người là đồng nghiệp. Không xa bên dưới bề mặt, có một API nội bộ cung cấp chức năng mà hai máy chủ cần.

Chúng tôi không biết về bất kỳ tiền lệ nào, vì vậy đó là loại thử nghiệm. Cho đến nay (sắp bước vào giai đoạn thử nghiệm), nó đã hoạt động khá tốt.

Tôi thường chọn tùy chọn thứ 2, sử dụng Rails để xây dựng API và xương sống cho các công cụ JS. Bạn thậm chí có thể nhận bảng điều khiển quản trị miễn phí bằng ActiveAdmin . Tôi đã chuyển hàng chục ứng dụng di động với loại phụ trợ này. Tuy nhiên, nó phụ thuộc rất nhiều vào việc ứng dụng của bạn có tương tác hay không.

Tôi đã trình bày về cách tiếp cận này tại RubyDay.it cuối cùng : http://www.sl slideshoware.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Đối với tùy chọn thứ ba, để có được phản hồi của tùy chọn thứ hai, bạn có thể muốn thử dùng pyjax như Github.

Tôi có khoảng 2 tháng trong một dự án 3 tháng theo cách tiếp cận thứ hai mà bạn đã vạch ra ở đây. Chúng tôi sử dụng phía máy chủ API RESTful với backbone.js ở mặt trước. Handlebars.js quản lý các mẫu và jQuery xử lý thao tác AJAX và DOM. Đối với các trình duyệt và trình tìm kiếm cũ hơn, chúng tôi đã quay lại kết xuất phía máy chủ, nhưng chúng tôi đang sử dụng các mẫu HTML giống như giao diện Tay cầm sử dụng Mozilla Rhino.

Chúng tôi đã chọn cách tiếp cận này vì nhiều lý do khác nhau nhưng rất ý thức rằng nó có một chút rủi ro vì nó chưa được chứng minh trên diện rộng. Tất cả đều giống nhau, mọi thứ đều suôn sẻ cho đến nay.

Cho đến nay chúng ta mới làm việc với một API, nhưng trong giai đoạn tiếp theo của dự án, chúng ta sẽ làm việc với API thứ hai. Đầu tiên là cho một lượng lớn dữ liệu và thứ hai hoạt động giống như một CMS thông qua API.

Có hai phần của dự án hoạt động hoàn toàn độc lập với nhau là một cân nhắc quan trọng trong việc lựa chọn cơ sở hạ tầng này. Nếu bạn đang tìm kiếm một kiến ​​trúc để trộn các tài nguyên độc lập khác nhau mà không có bất kỳ sự phụ thuộc nào thì đây là cách tiếp cận đáng để xem xét.

Tôi sợ tôi không phải là một người Ruby nên tôi không thể nhận xét về các phương pháp khác. Đôi khi không thể chấp nhận rủi ro. Những lần khác, tốt hơn là chơi nó an toàn. Bạn sẽ nợ mình tùy thuộc vào loại dự án.

Tốt nhất của may mắn với sự lựa chọn của bạn ở đây. Quan tâm để xem những gì người khác chia sẻ là tốt.

Tôi thích # 3 khi trang web của tôi sẽ không được triển khai 100% CRUD cho dữ liệu của tôi. Điều này vẫn chưa xảy ra.

Tôi thích sinatra và sẽ chỉ chia ứng dụng thành một vài ứng dụng rack khác nhau với các mục đích khác nhau. Tôi sẽ tạo một ứng dụng giá cụ thể API sẽ bao gồm những gì tôi cần cho API. Sau đó, có lẽ một ứng dụng rack người dùng sẽ trình bày trang web của tôi. Đôi khi phiên bản đó sẽ truy vấn API nếu cần, nhưng thường thì nó chỉ liên quan đến trang html.

Tôi không lo lắng về điều đó và chỉ cần thực hiện một truy vấn lớp liên tục từ phía người dùng nếu tôi cần. Tôi không quá quan tâm đến việc tạo ra một sự tách biệt hoàn toàn vì chúng thường kết thúc phục vụ các mục đích khác nhau.

Dưới đây là một ví dụ rất đơn giản về việc sử dụng nhiều ứng dụng rack. Tôi đã thêm một ví dụ jquery nhanh trong đó để bạn thấy nó nhấn ứng dụng API. Bạn có thể thấy nó đơn giản như thế nào với sinatra và gắn nhiều ứng dụng rack với các mục đích khác nhau.

https://github.com/dusty/multi-rack-app-app

Một số câu trả lời tuyệt vời đã có ở đây - tôi chắc chắn khuyên bạn nên # 2 hoặc # 3 - sự phân tách là tốt về mặt khái niệm nhưng cũng trong thực tế.

Thật khó để dự đoán những thứ như tải và mẫu lưu lượng truy cập trên API và khách hàng chúng tôi thấy những người phục vụ API độc lập có thời gian cung cấp và nhân rộng dễ dàng hơn. Nếu bạn phải làm điều đó với các mẫu truy cập web của con người thì sẽ không dễ dàng gì. Ngoài ra, việc sử dụng API của bạn có thể sẽ tăng nhanh hơn rất nhiều so với ứng dụng web của bạn và sau đó bạn có thể thấy nơi để hướng những nỗ lực của mình.

Giữa # 2 # 3, điều này thực sự phụ thuộc vào mục tiêu của bạn - Tôi đồng ý rằng # 2 có thể là tương lai của các ứng dụng web - nhưng có lẽ bạn muốn một cái gì đó đơn giản hơn nếu kênh đó chỉ là một trong số nhiều!

Đối với atyourservice.com.cy, chúng tôi đang sử dụng các mẫu được hiển thị phía máy chủ cho các trang đặc biệt là để che phần se. Và sử dụng API cho các tương tác sau khi tải trang. Vì khung của chúng tôi là MVC, tất cả các chức năng của bộ điều khiển được sao chép thành đầu ra json và đầu ra html. Mẫu được sạch sẽ và chỉ nhận được một đối tượng. Điều này có thể được chuyển đổi sang các mẫu js trong vài giây. Chúng tôi luôn duy trì các mẫu máy chủ và chỉ chuyển đổi lại thành js theo yêu cầu.

Kết xuất đẳng hình và tăng cường lũy ​​tiến. Đó là những gì tôi nghĩ rằng bạn đã hướng đến trong lựa chọn ba.

Kết xuất đẳng hình có nghĩa là sử dụng cùng một khuôn mẫu để tạo phía máy chủ đánh dấu khi bạn sử dụng trong mã phía máy khách. Chọn một ngôn ngữ tạo khuôn mẫu với các triển khai phía máy chủ và phía máy khách tốt. Tạo html nướng hoàn toàn cho người dùng của bạn và gửi nó xuống dây. Sử dụng bộ nhớ đệm quá.

tăng cường tiến bộ có nghĩa là bắt đầu thực hiện phía máy khách và kết xuất và lắng nghe sự kiện một khi bạn đã tải xuống tất cả các tài nguyên và bạn có thể xác định các khả năng của máy khách. Trở lại chức năng không có kịch bản ứng dụng khách bất cứ nơi nào có thể để truy cập và tương thích ngược.

Vâng, tất nhiên viết một api json độc lập cho chức năng ứng dụng này. Nhưng đừng đi xa đến mức bạn viết một api json cho những thứ hoạt động tốt như các tài liệu html tĩnh.

Máy chủ REST + Máy khách nặng JavaScript là nguyên tắc tôi đã tuân theo trong công việc gần đây.

Máy chủ REST đã được triển khai trong node.js + Express + MongoDB (hiệu suất viết rất tốt) + Mongoose ODM (tuyệt vời để mô hình hóa dữ liệu, bao gồm các xác nhận hợp lệ) + CoffeeScript (bây giờ tôi sẽ chuyển sang ES2015). Node.js có thể còn khá trẻ so với các công nghệ phía máy chủ khác, nhưng tôi có thể viết API vững chắc với các khoản thanh toán được tích hợp.

Tôi đã sử dụng Ember.js làm khung JavaScript và hầu hết logic ứng dụng đã được thực thi trong trình duyệt. Tôi đã sử dụng SASS (cụ thể là SCSS) để xử lý trước CSS.

Ember là khuôn khổ trưởng thành được hỗ trợ bởi cộng đồng mạnh mẽ. Đó là khuôn khổ rất mạnh mẽ với rất nhiều công việc được thực hiện gần đây tập trung vào hiệu suất, như công cụ kết xuất Glimmer hoàn toàn mới (lấy cảm hứng từ React).

Nhóm Ember Core đang trong quá trình phát triển FastBoot , cho phép bạn thực thi logic Ember JavaScript của mình ở phía máy chủ (cụ thể là node.js) và gửi HTML được kết xuất sẵn của ứng dụng của bạn (thường được chạy trong trình duyệt) cho người dùng. Thật tuyệt vời cho SEO và trải nghiệm người dùng vì anh ta không đợi quá lâu để trang được hiển thị.

Ember CLI là công cụ tuyệt vời giúp bạn tổ chức mã của mình và nó đã hoạt động tốt để mở rộng quy mô. Ember cũng có hệ sinh thái addon riêng và bạn có thể chọn từ nhiều Addon Ember . Bạn có thể dễ dàng lấy Bootstrap (trong trường hợp của tôi) hoặc Foundation và thêm nó vào ứng dụng của bạn.

Không phục vụ mọi thứ qua Express, tôi đã chọn sử dụng nginx để phục vụ hình ảnh và ứng dụng khách nặng JavaScript. Sử dụng nginx proxy rất hữu ích trong trường hợp của tôi:

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro: Tôi thích sự tách biệt của API & client. Người thông minh nói rằng đây là con đường để đi. Tuyệt vời trong lý thuyết. Có vẻ tiên tiến và thú vị.

Tôi có thể nói nó cũng tuyệt vời trong thực tế. Một ưu điểm khác của việc tách API REST là bạn có thể sử dụng lại nó sau này cho các ứng dụng khác. Trong thế giới hoàn hảo, bạn sẽ có thể sử dụng cùng API REST không chỉ cho trang web mà còn cho các ứng dụng di động nếu bạn quyết định viết một API.

Con: Không có nhiều tiền lệ. Không có nhiều ví dụ về điều này được thực hiện tốt. Các ví dụ công khai (twitter.com) cảm thấy chậm chạp & thậm chí đang chuyển hướng khỏi phương pháp này.

Bây giờ mọi thứ đã khác. Có rất nhiều ví dụ về việc thực hiện API REST + nhiều khách hàng sử dụng nó.

Tôi quyết định chọn kiến ​​trúc của Lựa chọn số 2 cho Infiniforms , vì nó cung cấp một cách tuyệt vời để tách giao diện người dùng khỏi logic nghiệp vụ.

Một lợi thế của điều này là Máy chủ API có thể mở rộng độc lập với các máy chủ web. Nếu bạn có nhiều máy khách, thì các trang web sẽ không cần phải mở rộng quy mô giống như các máy chủ web, vì một số máy khách sẽ là điện thoại / máy tính bảng hoặc máy tính để bàn.

Cách tiếp cận này cũng cung cấp cho bạn một cơ sở tốt để mở API cho người dùng của bạn, đặc biệt nếu bạn sử dụng API của riêng mình để cung cấp tất cả các chức năng cho trang web của bạn.

Một câu hỏi rất hay và tôi ngạc nhiên vì tôi nghĩ rằng đây là một nhiệm vụ rất phổ biến hiện nay vì vậy tôi sẽ có nhiều nguồn lực cho vấn đề này, tuy nhiên hóa ra không phải là sự thật.

Suy nghĩ của tôi như sau: - Tạo một số mô-đun có logic chung giữa bộ điều khiển API và bộ điều khiển HTML mà không trả về json hoặc kết xuất html và bao gồm mô-đun này trong cả bộ điều khiển HTML và bộ điều khiển API, sau đó làm bất cứ điều gì bạn muốn, ví dụ: :

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

Tôi đã thực hiện một cách tiếp cận hỗn hợp trong đó chúng tôi sử dụng Sinatra làm cơ sở, ActiveRecord / PostTHER, v.v. để phục vụ các tuyến trang (mẫu mỏng) hiển thị API REST mà ứng dụng web có thể sử dụng. Trong các công cụ phát triển ban đầu như điền các tùy chọn chọn được thực hiện thông qua các trình trợ giúp hiển thị vào mẫu mỏng, nhưng khi chúng tôi tiếp cận quá trình sản xuất, điều này sẽ bị hoán đổi cho một cuộc gọi AJAX đến API REST khi chúng tôi bắt đầu quan tâm nhiều hơn về tốc độ tải trang.

Những thứ dễ dàng hiển thị trong Slim được xử lý theo cách đó và những thứ (biểu mẫu điền, nhận dữ liệu POST từ jQuery.Validation, submitHandlerv.v., rõ ràng là AJAX)

Kiểm tra là một vấn đề. Ngay bây giờ tôi đang cố gắng chuyển dữ liệu JSON sang thử nghiệm Rack :: Test POST .

Cá nhân tôi thích tùy chọn (3) là một giải pháp. Nó được sử dụng trong tất cả các trang web mà một chủ nhân trước đây (tên hộ gia đình) của tôi có. Điều đó có nghĩa là bạn có thể nhận được một số nhà phát triển giao diện người biết tất cả về Javascript, các yêu cầu của trình duyệt và không có gì để mã hóa giao diện người dùng của bạn. Họ chỉ cần biết "curl xyz và bạn sẽ nhận được một số json" và họ sẽ đi.

Trong khi đó, những anh chàng hậu vệ nặng ký của bạn có thể mã hóa các nhà cung cấp Json. Những người này không cần phải suy nghĩ về việc trình bày, và thay vào đó lo lắng về các phụ trợ dễ hỏng, hết thời gian, xử lý lỗi duyên dáng, nhóm kết nối cơ sở dữ liệu, phân luồng và chia tỷ lệ, v.v.

Tùy chọn 3 cung cấp cho bạn một kiến ​​trúc ba tầng tốt, vững chắc. Điều đó có nghĩa là những thứ bạn nhổ ra từ giao diện người dùng rất thân thiện với SEO, có thể được tạo để hoạt động với các trình duyệt cũ hoặc mới (và những trình duyệt đã tắt) và vẫn có thể tạo khuôn mẫu phía máy khách Javascript nếu bạn muốn (vì vậy bạn có thể làm những việc như xử lý các trình duyệt cũ / googlebot bằng HTML tĩnh, nhưng gửi JS trải nghiệm động được xây dựng cho mọi người bằng trình duyệt Chrome mới nhất hoặc bất cứ điều gì).

Trong tất cả các trường hợp tôi đã thấy Tùy chọn 3, đó là một triển khai tùy chỉnh của một số PHP không đặc biệt có thể chuyển nhượng giữa các dự án, chứ đừng nói gì đến đất Nguồn mở. Tôi đoán gần đây PHP có thể đã được thay thế bằng Ruby / Rails, nhưng điều tương tự vẫn đúng.

FWIW, $ current_employer có thể làm với Tùy chọn 3 ở một vài vị trí quan trọng. Tôi đang tìm kiếm một khung công tác Ruby tốt để xây dựng một cái gì đó. Tôi chắc chắn rằng tôi có thể kết dính một khối đá quý với nhau, nhưng tôi thích một sản phẩm duy nhất cung cấp rộng rãi một giải pháp lưu trữ kết nối templating, 'curling', xác thực tùy chọn, memcache / nosql tùy chọn. Ở đó tôi không tìm thấy bất cứ điều gì mạch lạc :-(

Xây dựng API JSON trong Rails là lớp đầu tiên, JSONAPI :: Tài nguyên đá quý thực hiện công việc nặng nề cho một API đặc tả http://jsonapi.org .