The only useful paradigm to write in Flask is MethodView's for me [1]
because decorators seem hard to refactor for large projects. Please look
at adding URLs -- one has to additionally specify methods to match those
from the MethodView -- this is code duplication and looks ugly.
It seems though that Fask-RESTful [2] fixes this but then we're
dependent on 2 projects.
I don't like that Flask uses a global request object [3]. From Flask
documentation
"Basically you can completely ignore that this is the case unless you
are doing something like unit testing. You will notice that code which
depends on a request object will suddenly break because there is no
request object. The solution is creating a request object yourself and
binding it to the context."
Yeah, let's make testing even harder...
Pecan looks better in respect of RESTful services [4].
POST parameters are cleanly passed as arguments to the post method. It
also provides custom JSON serialization hooks [5] so we can forget about
explicit serialization in handlers.
So from these 2 choices I'm for Pecan.
[1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
[2] https://flask-restful.readthedocs.org/en/0.3.0/
[3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
[4] http://pecan.readthedocs.org/en/latest/rest.html
[5] http://pecan.readthedocs.org/en/latest/jsonify.html
P.
On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:
We had used Flask in the fuel-stats. It was easy and pleasant and all
project requirements was satisfied. And I saw difficulties and
workarounds with Pecan, when Nick integrated it into Nailgun.
So +1 for Flask.
On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov <nmar...@mirantis.com
<mailto:nmar...@mirantis.com>> wrote:
Michael, we already solved all issues I described, and I just don't
want to solve them once again after moving to another framework. Also,
I think, nothing of these wishes contradicts with good API design.
On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
<krotsch...@gmail.com <mailto:krotsch...@gmail.com>> wrote:
> This sounds more like you need to pay off technical debt and
clean up your
> API.
>
> Michael
>
> On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov
<nmar...@mirantis.com <mailto:nmar...@mirantis.com>>
> wrote:
>>
>> Hello all,
>>
>> I actually tried to use Pecan and even created a couple of
PoCs, but
>> there due to historical reasons of how our API is organized it will
>> take much more time to implement all workarounds we need to issues
>> Pecan doesn't solve out of the box, like working with non-RESTful
>> URLs, reverse URL lookup, returning custom body in 404 response,
>> wrapping errors to JSON automatically, etc.
>>
>> As far as I see, each OpenStack project implements its own
workarounds
>> for these issues, but still it requires much less men and hours
for us
>> to move to Flask-Restful instead of Pecan, because all these
problems
>> are already solved there.
>>
>> BTW, I know a lot of pretty big projects using Flask (it's the
second
>> most popular Web framework after Django in Python Web
community), they
>> even have their own "hall of fame":
>> http://flask.pocoo.org/community/poweredby/ .
>>
>> On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown <rybr...@redhat.com
<mailto:rybr...@redhat.com>> wrote:
>> > On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
>> >> Hi, Sebastian,
>> >>
>> >> Thank you for raising this topic again.
>> >>
>> >> [snip]
>> >>
>> >> Personally, I'd like to use Flask instead of Pecan, because
first one
>> >> is more production-ready tool and I like its design. But I
believe
>> >> this should be resolved by voting.
>> >>
>> >> Thanks,
>> >> Igor
>> >>
>> >> On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
>> >> <skalinow...@mirantis.com <mailto:skalinow...@mirantis.com>>
wrote:
>> >>> Hi all,
>> >>>
>> >>> [snip explanation+history]
>> >>>
>> >>> Best,
>> >>> Sebastian
>> >
>> > Given that Pecan is used for other OpenStack projects and has
plenty of
>> > builtin functionality (REST support, sessions, etc) I'd
prefer it for a
>> > number of reasons.
>> >
>> > 1) Wouldn't have to pull in plugins for standard (in Pecan)
things
>> > 2) Pecan is built for high traffic, where Flask is aimed at
much smaller
>> > projects
>> > 3) Already used by other OpenStack projects, so common
patterns can be
>> > reused as oslo libs
>> >
>> > Of course, the Flask community seems larger (though the
average flask
>> > project seems pretty small).
>> >
>> > I'm not sure what determines "production readiness", but it
seems to me
>> > like Fuel developers fall more in Pecan's target audience than in
>> > Flask's.
>> >
>> > My $0.02,
>> > Ryan
>> >
>> > --
>> > Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Best regards,
>> Nick Markov
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Best regards,
Nick Markov
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
