Flask vs webapp2 cho Google App Engine

Question

Tôi đang bắt đầu ứng dụng Google App Engine mới và hiện đang xem xét hai khung: Flask và webapp2. Tôi khá hài lòng với khung công tác webapp được tích hợp sẵn mà tôi đã sử dụng cho ứng dụng App Engine trước đây của mình, vì vậy tôi nghĩ webapp2 sẽ tốt hơn và tôi sẽ không gặp bất kỳ vấn đề nào với nó.

Tuy nhiên, có rất nhiều đánh giá tốt về Flask, tôi thực sự thích cách tiếp cận của nó và tất cả những điều tôi đã đọc cho đến nay trong tài liệu và tôi muốn dùng thử. Nhưng tôi hơi lo ngại về những hạn chế mà tôi có thể đối mặt với con đường với Flask. Vì vậy, câu hỏi là - bạn có biết bất kỳ sự cố, vấn đề hiệu suất, giới hạn nào (ví dụ: hệ thống định tuyến, cơ chế ủy quyền tích hợp, v.v.) mà Flask có thể đưa vào ứng dụng Google App Engine không? Không. Bởi "vấn đề" Tôi có nghĩa là một cái gì đó mà tôi không thể làm việc xung quanh trong một số dòng mã (hoặc bất kỳ số tiền hợp lý của mã và nỗ lực) hoặc một cái gì đó là hoàn toàn không thể.

Và như một câu hỏi tiếp theo: có bất kỳ tính năng sát thủ nào trong Flask mà bạn nghĩ có thể thổi tâm trí của tôi và khiến tôi sử dụng nó bất chấp mọi vấn đề mà tôi có thể gặp phải không?

Answer 1

Tuyên bố từ chối trách nhiệm: Tôi là tác giả của tipfy và webapp2.

Một lợi thế lớn của việc gắn bó với webapp Ví dụ, deferred sử dụng trình xử lý webapp. Để sử dụng nó trong chế độ xem Flask thuần túy, sử dụng werkzeug.Request và werkzeug.Response, bạn sẽ cần phải thực hiện hoãn lại cho nó (như tôi đã làm here cho mẹo). Điều này cũng xảy ra đối với các trình xử lý khác: blobstore (Werkzeug vẫn không hỗ trợ các yêu cầu phạm vi, vì vậy bạn sẽ cần sử dụng WebOb ngay cả khi bạn tạo trình xử lý riêng của mình - xem tipfy.appengine.blobstore), mail, XMPP v.v. hoặc những người khác được bao gồm trong SDK trong tương lai.

Và điều tương tự cũng xảy ra đối với thư viện được tạo bằng App Engine, như ProtoRPC, dựa trên webapp và cần cổng hoặc bộ điều hợp để làm việc với các khung công tác khác, nếu bạn không muốn kết hợp ứng dụng web và bộ xử lý khung lựa chọn trong cùng một ứng dụng. Vì vậy, ngay cả khi bạn chọn một khung công tác khác, bạn sẽ kết thúc a) bằng cách sử dụng webapp trong một số trường hợp đặc biệt hoặc b) phải tạo và duy trì phiên bản của bạn cho các trình xử lý hoặc tính năng SDK cụ thể, nếu bạn sử dụng chúng.Tôi thích Werkzeug hơn WebOb, nhưng sau hơn một năm porting và duy trì các phiên bản của bộ xử lý SDK làm việc với tipfy, tôi nhận ra rằng đây là một nguyên nhân bị mất - để hỗ trợ GAE cho lâu dài, tốt nhất là để ở gần webapp/WebOb. Nó giúp cho các thư viện SDK trở nên dễ dàng hơn, việc bảo trì trở nên dễ dàng hơn nhiều, tương thích hơn vì các thư viện mới và các tính năng SDK sẽ hoạt động và có lợi ích của một cộng đồng lớn hoạt động trên cùng một công cụ App Engine.

Một quốc phòng webapp2 cụ thể được tóm tắt here. Thêm vào số đó webapp2 can be used outside of App Engine và là easy to be customized to look like popular micro-frameworks và bạn có một bộ lý do thuyết phục để thực hiện. Ngoài ra, webapp2 có cơ hội lớn để được đưa vào bản phát hành SDK trong tương lai (điều này là chính thức hơn, không báo cho tôi :-) sẽ đẩy nó về phía trước và mang lại các nhà phát triển và đóng góp mới.

Điều đó nói rằng, tôi là một fan hâm mộ lớn của Werkzeug và những người Pocoo và vay mượn rất nhiều từ Flask và những người khác (web.py, Tornado), nhưng - và, bạn biết đấy, tôi thiên vị - lợi ích trên webapp2 cần được tính đến.

Answer 2

Câu hỏi của bạn cực kỳ rộng, nhưng dường như không có vấn đề gì lớn khi sử dụng Flask trên Google App Engine.

mailing list này chủ đề liên kết đến một số mẫu:

http://flask.pocoo.org/mailinglist/archive/2011/3/27/google-app-engine/#4f95bab1627a24922c60ad1d0a0a8e44

Và đây là một hướng dẫn cụ thể cho các cơ kết hợp Flask/App:

http://www.franciscosouza.com/2010/08/flying-with-flask-on-google-app-engine/

Ngoài ra, xem App Engine - Difficulty Accessing Twitter Data - Flask, Flask message flashing fails across redirects và How do I manage third-party Python libraries with Google App Engine? (virtualenv? pip?) cho các sự cố mọi người gặp phải với Flask và Google App Engine.

Answer 3

Tôi đã không thử webapp2 và thấy rằng mẹo nhỏ khó sử dụng vì nó yêu cầu các tập lệnh thiết lập và xây dựng cấu hình cài đặt python của bạn khác với mặc định. Vì vậy, tôi không tạo ra dự án lớn nhất phụ thuộc vào khung công tác và tôi sử dụng webapp đơn giản thay vào đó, thêm thư viện có tên là cốc để có khả năng phiên và django đã có sẵn bản dịch cho các từ phổ biến cho nhiều giai đoạn khác nhau ứng dụng địa phương django là sự lựa chọn đúng cho dự án lớn nhất của tôi. Hai khung công tác khác mà tôi thực sự triển khai với các dự án vào môi trường sản xuất là GAEframework.com và web2py và nói chung có vẻ như việc thêm một khuôn khổ thay đổi công cụ mẫu của nó có thể dẫn đến sự không tương thích giữa các phiên bản cũ và mới. Vì vậy, kinh nghiệm của tôi là tôi không muốn thêm một khuôn khổ cho các dự án của tôi trừ khi họ giải quyết các trường hợp sử dụng nâng cao hơn (tải lên tệp, đa xác thực, quản trị viên là 3 ví dụ về các trường hợp sử dụng nâng cao hơn mà không có khung gae vào lúc này xử lý cũng

Answer 4

tôi nghĩ rằng công cụ ứng dụng google chính thức hỗ trợ khuôn khổ bình có một mã mẫu và hướng dẫn ở đây -..>https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

Answer 5

đối với tôi quyết định cho webapp2 là dễ dàng khi tôi phát hiện ra bình đó là không phải là khung công tác hướng đối tượng (từ đầu), trong khi webapp2 là một khung định hướng đối tượng thuần túy. webapp2 sử dụng phương thức Dispatching theo phương thức như là tiêu chuẩn cho tất cả RequestH andlers (như tài liệu bình gọi nó và thực hiện nó từ V0.7 trong MethodViews). Trong khi trong MethodViews bình là một add-on nó là một nguyên tắc thiết kế cốt lõi cho webapp2. Vì vậy, thiết kế phần mềm của bạn sẽ trông khác nhau bằng cách sử dụng cả hai khung công tác. Cả hai khuôn khổ đều sử dụng các mẫu jinja2 ngày nay và khá giống nhau.

Tôi muốn thêm kiểm tra bảo mật vào lớp RequestHandler cấp cơ sở và kế thừa từ đó. Điều này cũng tốt cho các chức năng tiện ích, v.v. Như bạn có thể thấy ví dụ trong liên kết [3], bạn có thể ghi đè lên các phương thức để ngăn chặn việc gửi yêu cầu.

Nếu bạn là người OO hoặc nếu bạn cần thiết kế máy chủ REST, tôi khuyên bạn nên sử dụng webapp2 cho bạn. Nếu bạn thích các chức năng đơn giản với trang trí như bộ điều khiển cho nhiều loại yêu cầu, hoặc bạn không thoải mái với thừa kế OO thì hãy chọn bình. Tôi nghĩ rằng cả hai khuôn khổ tránh sự phức tạp và phụ thuộc của các khuôn khổ lớn hơn nhiều như kim tự tháp.

1. http://flask.pocoo.org/docs/0.10/views/#method-based-dispatching
2. https://webapp-improved.appspot.com/guide/handlers.html
3. https://webapp-improved.appspot.com/guide/handlers.html#overriding-dispatch