Flask so với webapp2 dành cho Google App Engine

Tôi đang bắt đầu ứng dụng Google App Engine mới và hiện đang xem xét hai khuôn khổ: Flask và webapp2 . Tôi khá hài lòng với khung ứng dụng web 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ẽ còn tốt hơn nữa 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 mà 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ể gặp phải với Flask.

Vì vậy, câu hỏi đặt ra là - bạn có biết bất kỳ vấn đề, vấn đề hiệu suất, hạn chế 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? "Vấn đề", ý tôi là một điều gì đó mà tôi không thể giải quyết được trong một vài dòng mã (hoặc bất kỳ số lượng mã hợp lý và nỗ lực nào) hoặc điều gì đó 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 bay 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?

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 (hoặc sự phát triển tự nhiên của nó, webapp2) là bạn không phải tạo các phiên bản của riêng mình cho các trình xử lý SDK hiện có cho khuôn khổ mà bạn chọn.

Ví dụ: hoãn lại sử dụng trình xử lý ứng dụng web. Để sử dụng nó trong chế độ xem Flask thuần túy, bằng cách sử dụng werkzeug.Request và werkzeug.Response, bạn sẽ cần phải triển khai hoãn lại cho nó (giống như tôi đã làm ở đây cho tipfy).

Điều tương tự 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ý của riêng mình - xem tipfy.appengine.blobstore ), mail, XMPP, v.v. hoặc những thứ khác được đưa vào SDK trong tương lai.

Và điều tương tự cũng xảy ra đối với các thư viện được tạo bằng App Engine, như ProtoRPC , dựa trên ứng dụng web và sẽ cần một cổng hoặc bộ điều hợp để hoạt động 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à khuôn khổ-của- trình xử lý 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 việc a) sử dụng ứng dụng web trong một số trường hợp đặc biệt hoặc b) phải tạo và duy trì các phiên bản của mình cho các trình xử lý hoặc tính năng SDK cụ thể, nếu bạn sẽ sử dụng chúng.

Tôi thích Werkzeug hơn WebOb, nhưng sau hơn một năm chuyển và duy trì các phiên bản của trình xử lý SDK hoạt động nguyên bản với tipfy, tôi nhận ra rằng đây là một nguyên nhân mất tích - để hỗ trợ GAE về lâu dài, tốt nhất là bạn nên tiếp cận với webapp / WebOb. Nó giúp cho việc hỗ trợ các thư viện SDK trở nên dễ dàng hơn rất nhiều, việc bảo trì trở nên dễ dàng hơn rất nhiều, nó dễ chứng minh hơn trong tương lai vì các thư viện và tính năng SDK mới sẽ hoạt động hiệu quả và có lợi ích của một cộng đồng lớn làm việc trên cùng các công cụ App Engine.

Một biện pháp bảo vệ webapp2 cụ thể được tóm tắt ở đây . Thêm vào đó, webapp2 có thể được sử dụng bên ngoài App Engine và dễ dàng được tùy chỉnh để trông giống như các khuôn khổ vi mô phổ biến và bạn có một loạt lý do thuyết phục để sử dụng 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 (đây là bản phát hành bổ sung chính thức, đừng trích dẫn tôi :-). Điều này sẽ thúc đẩy nó về phía trước và mang lại cho các nhà phát triển và đóng góp mới.

Điều đó nói rằng, tôi là một người 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ị - những lợi ích webapp2 trên nên được tính đến.

Câu hỏi của bạn rất 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.

Chuỗi danh sách gửi thư này 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à hướng dẫn cụ thể cho sự kết hợp Flask / App Engine:

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

Ngoài ra, hãy xem Công cụ ứng dụng - Khó truy cập dữ liệu Twitter - Bình , nhấp nháy thông báo trong bình không thành công khi chuyển hướng và Làm cách nào để quản lý thư viện Python của bên thứ ba với Google App Engine? (virtualenv? pip?) cho các vấn đề mọi người gặp phải với Flask và Google App Engine.

Đối với tôi, quyết định cho webapp2 rất dễ dàng khi tôi phát hiện ra rằng flask không phải là một khung hướng đối tượng (ngay từ đầu), trong khi webapp2 là một khung hướng đối tượng thuần túy. webapp2 sử dụng Điều phối dựa trên phương pháp làm tiêu chuẩn cho tất cả các RequestHandlers (như tài liệu bình gọi nó và triển khai nó kể từ V0.7 trong MethodViews). Mặc dù trong flask MethodViews là một tiện ích bổ sung, 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 khi sử dụng cả hai khuôn khổ. Cả hai framework đều sử dụng các mẫu jinja2 ngày nay và có tính năng khá giống nhau.

Tôi muốn thêm các kiểm tra bảo mật vào RequestHandler lớp cơ sở và kế thừa từ nó. Đ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 đè các phương thức để ngă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ột máy chủ REST, tôi sẽ giới thiệu webapp2 cho bạn. Nếu bạn thích các chức năng đơn giản với trình trang trí là trình xử lý 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 framework đều tránh được sự phức tạp và phụ thuộc của các framework 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

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

Tôi đã không thử webapp2 và nhận thấy rằng tipfy hơi khó sử dụng vì nó yêu cầu tập lệnh thiết lập và bản dựng cấu hình cài đặt python của bạn thành khác với mặc định. Vì những lý do này và những lý do khác, tôi đã không thực hiện dự án lớn nhất của mình phụ thuộc vào một khuôn khổ và thay vào đó, tôi sử dụng ứng dụng web đơn giản, thêm thư viện có tên là beaker để có khả năng phiên và django đã có bản dịch nội dung cho các từ phổ biến với nhiều cách sử dụng, vì vậy khi xây dựng một ứng dụng bản địa hóa django là lựa chọn phù hợp 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 cho môi trường sản xuất là GAEframework.com và web2py và nhìn chung, có vẻ như việc thêm một khung làm việc 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 đang miễn cưỡng thêm một khuôn khổ vào các dự án của mình trừ khi chúng 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, ui quản trị là 3 ví dụ về các trường hợp sử dụng nâng cao hơn mà không có khuôn khổ nào cho gae vào lúc này xử lý tốt.