On Tue, 04 Oct 2011, Tibor Simko wrote: > <http://invenio-software.org/wiki/Talk/WebFrameworks>
To recap, at the Invenio Developers Forum last Monday, we have narrowed down the web framework choice to three main candidates (Flask/Werkzeug, Pyramid, Tornado) and we planned to pursue our selection by email and chat discussions, aiming at shortlisting candidates even more, checking whether we converge, and possibly making another telecon on Thursday in order to finalise the choice. Thursday approaching, let me try to briefly summarise the feelings here at CERN, as discussed among several Invenio and INSPIRE developers in the past few days. (Notably Carmen, JanL, Javier, Jerome, Ludmila, SamK, and myself.) - Out of the three framework candidates, two are WSGI friendly, Flask and Pyramid. Out of Flask and Pyramid, we seem to prefer Flask. Both technically, due to Werkzeug vs Paste/WebOb middleware, as well as non-technically, as per the other criteria discussed previously (community, presence, etc). After looking further at Pyramid, it did not seem like we would be lacking anything obvious feature-wise should we stick to our preference. So after weighting it all out, we propose to eliminate Pyramid from the shortlist and retain Flask. - This leaves us with Flask versus Tornado, which is an interesting choice. Technically, Tornado provides a different asynchronous cooperative multitasking paradigm when compared to the usual processes and threads used in WSGI web apps. OT1H, this is an interesting approach that opens new perspective and possibilities; OTOH, paradigm change would probably result in steeper migration, there is a danger of possible lockups in our WSGI and DB driven application and dependencies to assess, etc. Since we start from a well assessed WSGI context and since we want to move quickly, and since we don't seem to have many concrete Tornado-like asynchronous use cases as of yet, it looked like Flask is a better choice. Non-technically, e.g. community-wise, we preferred Flask as well. - Otherwise many developers here at CERN expressed to be OK with either of the proposed frameworks, without particular strong preference. I'd therefore tentatively summarise our position by saying that Flask/Werkzeug/Jinja seems to be our clear favourite. (But also that it would be very interesting to spend 3-4 weeks or so in order fully explore pros/cons/lockup-dangers/migration-work associated with switching to Tornado's paradigm for our concrete application, including building simplified prototype to re-measure search citation dictionary setup scalability, and stuff.) CERN hackers, please comment on in case my summary diverged someplace. Cornell/Harvard/SLAC hackers, please join in with your preferences and findings, to see whether we converge. We can make another telecon tomorrow at 16:30 in order to discuss the findings interactively and in more detail, if needed. Anyone, if you have not joined in the discussion yet, and if you have another suggestion to make, please holler! Best regards -- Tibor Simko
