Google App Engine 용 Flask 대 webapp2

새로운 Google App Engine 애플리케이션을 시작 중이며 현재 Flask 및 webapp2의 두 가지 프레임 워크를 고려하고 있습니다 . 이전 App Engine 애플리케이션에 사용했던 내장 웹앱 프레임 워크에 다소 만족하므로 webapp2가 더 나아질 것이며 문제가 없을 것입니다.

그러나 Flask에 대한 좋은 리뷰가 많이 있습니다. 저는 그 접근 방식과 지금까지 문서에서 읽은 모든 것을 정말 좋아하고 시험 해보고 싶습니다. 하지만 나는 Flask로 길을 잃을 수있는 한계에 대해 약간 걱정하고 있습니다.

따라서 문제는 -Flask가 Google App Engine 애플리케이션에 가져올 수있는 문제, 성능 문제, 제한 사항 (예 : 라우팅 시스템, 내장 권한 부여 메커니즘 등)을 알고 있습니까? "문제"란 여러 줄의 코드 (또는 합리적인 양의 코드와 노력)에서 해결할 수없는 것 또는 완전히 불가능한 것을 의미합니다.

그리고 후속 질문으로, Flask에 내가 직면 할 수있는 문제에도 불구하고 내 마음을 날려 버리고 사용하게 만들 수있는 킬러 기능이 있습니까?

면책 조항 : 저는 tipfy 및 webapp2의 저자입니다.

webapp (또는 자연스러운 진화, webapp2)를 고수 할 때의 큰 장점은 선택한 프레임 워크에 대해 기존 SDK 핸들러에 대한 자체 버전을 만들 필요가 없다는 것입니다.

예를 들어, deferred 는 webapp 핸들러를 사용합니다. 순수한 Flask 뷰에서 werkzeug.Request 및 werkzeug.Response를 사용하여 사용하려면 deferred를 구현해야합니다 ( 여기 에서 tipfy를 위해했던 것처럼).

다른 핸들러에서도 마찬가지입니다 : blobstore (Werkzeug는 여전히 범위 요청을 지원하지 않으므로 자체 핸들러를 생성하더라도 WebOb를 사용해야합니다 -tipfy.appengine.blobstore 참조 ), 메일, XMPP 등, 또는 향후 SDK에 포함될 기타.

웹앱을 기반으로하며 웹앱 과 프레임 워크를 혼합하지 않으려면 다른 프레임 워크와 작동하기 위해 포트 또는 어댑터가 필요한 ProtoRPC 와 같이 App Engine을 염두에두고 만든 라이브러리에서도 마찬가지 입니다. 같은 앱의 선택 핸들러.

따라서 다른 프레임 워크를 선택하더라도 a) 특별한 경우에 웹앱을 사용하거나 b) 특정 SDK 처리기 또는 기능을 사용할 경우 버전을 만들고 유지 관리해야합니다.

WebOb보다 Werkzeug를 훨씬 더 선호하지만, tipfy와 기본적으로 작동하는 SDK 핸들러 버전을 1 년 넘게 이식하고 유지 관리 한 후 이것이 손실 된 원인이라는 것을 깨달았습니다. 장기적으로 GAE를 지원하는 것이 가장 좋습니다. webapp / WebOb. SDK 라이브러리를 쉽게 지원하고 유지 관리가 훨씬 쉬워지며 새로운 라이브러리 및 SDK 기능이 즉시 작동하고 동일한 App Engine 도구를 중심으로 작업하는 대규모 커뮤니티의 이점이 있기 때문에 미래에 대비할 수 있습니다.

특정 webapp2 방어가 여기 에 요약되어 있습니다 . 그들에 추가 webapp2이 앱 엔진의 외부 사용할 수 있습니다 이며 인기있는 마이크로 프레임 워크처럼 보이도록 사용자 정의 할 쉽게 당신이 그것을 위해가는 특별한 이유의 좋은 세트를 가지고있다. 또한 webapp2는 향후 SDK 릴리스에 포함될 수있는 큰 기회가 있습니다 (이것은 비공식적이며 저를 인용하지 마십시오. :-). 앞으로 나아가고 새로운 개발자와 기여를 가져올 것입니다.

즉, 저는 Werkzeug와 Pocoo 사람들의 열렬한 팬이고 Flask 및 기타 (web.py, Tornado)에서 많은 것을 빌 렸지만-그리고 저는 편견입니다-위의 webapp2 혜택은 고려됩니다.

귀하의 질문은 매우 광범위하지만 Google App Engine에서 Flask를 사용하는 데 큰 문제는없는 것 같습니다.

이 메일 링리스트 스레드는 여러 템플릿에 연결됩니다.

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

다음은 Flask / App Engine 조합에 대한 가이드입니다.

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

또한 App Engine-Difficulty Accessing Twitter Data-Flask , Flask message flashing fails across redirects , and how do I manage third-party Python libraries with Google App Engine을 참조하세요. (virtualenv? pip?) 사람들이 Flask 및 Google App Engine에서 겪었던 문제에 대해 설명합니다.

플라스크가 처음부터 객체 지향 프레임 워크가 아닌 반면 webapp2는 순수한 객체 지향 프레임 워크라는 것을 알았을 때 webapp2에 대한 결정은 쉬웠습니다. webapp2는 모든 RequestHandlers에 대한 표준으로 Method Based Dispatching을 사용합니다 (플라스크 문서에서이를 호출하고 MethodViews에서 V0.7 이후로 구현 함). 플라스크에서 MethodViews는 추가 기능이지만 webapp2의 핵심 디자인 원칙입니다. 따라서 두 프레임 워크를 사용하면 소프트웨어 디자인이 다르게 보입니다. 두 프레임 워크 모두 요즘 jinja2 템플릿을 사용하며 기능이 상당히 동일합니다.

기본 클래스 RequestHandler에 보안 검사를 추가하고 상속하는 것을 선호합니다. 이것은 또한 유틸리티 함수 등에 유용합니다. 예를 들어 링크 [3]에서 볼 수 있듯이 요청 발송을 방지하기 위해 메서드를 재정의 할 수 있습니다.

OO 사람이거나 REST 서버를 설계해야하는 경우 webapp2를 권장합니다. 여러 요청 유형에 대한 핸들러로 데코레이터가있는 간단한 함수를 선호하거나 OO 상속이 불편한 경우 플라스크를 선택하십시오. 두 프레임 워크 모두 피라미드와 같은 훨씬 더 큰 프레임 워크의 복잡성과 종속성을 피한다고 생각합니다.

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

Google 앱 엔진이 공식적으로 플라스크 프레임 워크를 지원한다고 생각합니다. 여기에 샘플 코드와 튜토리얼이 있습니다-> https://console.developers.google.com/start/appengine?_ga=1.36257892.596387946.1427891855

나는 webapp2를 시도하지 않았고 tipfy는 파이썬 설치를 기본값이 아닌 다른 것으로 구성하는 설정 스크립트와 빌드가 필요했기 때문에 사용하기가 약간 어렵다는 것을 알았습니다. 이러한 이유와 다른 이유로 가장 큰 프로젝트를 프레임 워크에 의존하지 않고 대신 일반 웹앱을 사용하고 세션 기능을 얻기 위해 beaker라는 라이브러리를 추가하고 django는 이미 많은 사용 사례에 공통된 단어에 대한 내장 번역을 가지고 있으므로 현지화 된 애플리케이션 django는 가장 큰 프로젝트에 적합한 선택이었습니다. 실제로 프로젝트와 함께 프로덕션 환경에 배포 한 두 가지 다른 프레임 워크는 GAEframework.com 및 web2py였으며 일반적으로 템플릿 엔진을 변경하는 프레임 워크를 추가하면 이전 버전과 새 버전간에 비 호환성이 발생할 수 있습니다.

그래서 내 경험은 더 고급 사용 사례를 해결하지 않는 한 내 프로젝트에 프레임 워크를 추가하는 것을 꺼려한다는 것입니다 (파일 업로드, 다중 인증, 관리 UI는 현재 gae에 대한 프레임 워크가없는 고급 사용 사례의 3 가지 예입니다. 잘 처리합니다.