librelist archives

« back to archive

Django as a fallback for Falcon

Django as a fallback for Falcon

From:
Lucas Lobosque
Date:
2015-10-02 @ 13:41
Hello guys,

I am using uwsgi as the server and I wonder if it's possible to implement a
catch-all fallback that will route any request that isn't registered in
falcon to Django.
I want to do that in order to gradually port a system to falcon.
Any advise?
Thanks.

Re: [falcon] Django as a fallback for Falcon

From:
James Errico
Date:
2015-10-02 @ 13:52
Are Falcon and Django running on the same address\codebase or are they two
separate servers?

Thanks,
-James

On Fri, Oct 2, 2015 at 9:41 AM, Lucas Lobosque <
lucas.lobosque@contentools.com.br> wrote:

> Hello guys,
>
> I am using uwsgi as the server and I wonder if it's possible to implement
> a catch-all fallback that will route any request that isn't registered in
> falcon to Django.
> I want to do that in order to gradually port a system to falcon.
> Any advise?
> Thanks.
>

Re: [falcon] Django as a fallback for Falcon

From:
Lucas Lobosque
Date:
2015-10-02 @ 13:55
I want them to share the same codebase.

On Fri, Oct 2, 2015 at 10:52 AM, James Errico <jerrico@unifiedsocial.com>
wrote:

> Are Falcon and Django running on the same address\codebase or are they two
> separate servers?
>
> Thanks,
> -James
>
> On Fri, Oct 2, 2015 at 9:41 AM, Lucas Lobosque <
> lucas.lobosque@contentools.com.br> wrote:
>
>> Hello guys,
>>
>> I am using uwsgi as the server and I wonder if it's possible to implement
>> a catch-all fallback that will route any request that isn't registered in
>> falcon to Django.
>> I want to do that in order to gradually port a system to falcon.
>> Any advise?
>> Thanks.
>>
>
>

Re: [falcon] Django as a fallback for Falcon

From:
Henrik Tuborg
Date:
2015-10-02 @ 13:55
Without knowing your exact environment constraints, here is my suggestion:

I'd add something like nginx in front of all of it and defining two
upstreams, then letting routing rules in nginx determine what goes where.
This makes it super easy to define and manage (and reason about) where
traffic goes.
Then run django and falcon as two seperate servers (locally on different
ports, or actually on seperate servers, depending on the case).
I don't see any benefit in doing it from code. :)

If that solution won't fit for some reason or the other, let me know and
I'll try to explain how you could do it from code.






Cheers,
Henrik Tudborg
Tlf.:    (+45) 51 71 99 39
www.: tudb.org

2015-10-02 15:41 GMT+02:00 Lucas Lobosque <lucas.lobosque@contentools.com.br
>:

> Hello guys,
>
> I am using uwsgi as the server and I wonder if it's possible to implement
> a catch-all fallback that will route any request that isn't registered in
> falcon to Django.
> I want to do that in order to gradually port a system to falcon.
> Any advise?
> Thanks.
>

Re: [falcon] Django as a fallback for Falcon

From:
Lucas Lobosque
Date:
2015-10-02 @ 14:04
I want to do this because we are currently using Tastypie
<https://github.com/django-tastypie/django-tastypie> to write our API, but
it is getting to a point where performance is starting to be a problem.

The reason I want to share a codebase is that I have a lot of my
application logic implemented in the model layer, and switching the API
layer from tastypie to falcon would greatly improve our application
performance.
Then, after this first step, we would also get rid of django and use an
ORM-only solution for our model layer. (It wouldn't make sense to use
django if we are only using its ORM).

If I manage to route the requests from falcon to django, we can port the
whole thing gradually.

On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org> wrote:

> Without knowing your exact environment constraints, here is my suggestion:
>
> I'd add something like nginx in front of all of it and defining two
> upstreams, then letting routing rules in nginx determine what goes where.
> This makes it super easy to define and manage (and reason about) where
> traffic goes.
> Then run django and falcon as two seperate servers (locally on different
> ports, or actually on seperate servers, depending on the case).
> I don't see any benefit in doing it from code. :)
>
> If that solution won't fit for some reason or the other, let me know and
> I'll try to explain how you could do it from code.
>
>
>
>
>
>
> Cheers,
> Henrik Tudborg
> Tlf.:    (+45) 51 71 99 39
> www.: tudb.org
>
> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
> lucas.lobosque@contentools.com.br>:
>
>> Hello guys,
>>
>> I am using uwsgi as the server and I wonder if it's possible to implement
>> a catch-all fallback that will route any request that isn't registered in
>> falcon to Django.
>> I want to do that in order to gradually port a system to falcon.
>> Any advise?
>> Thanks.
>>
>
>

Re: [falcon] Django as a fallback for Falcon

From:
Michał Jaworski
Date:
2015-10-02 @ 14:30
Henrik's idea is what I would recommend too. It's good approach. Having
catch-all fallback will only make harder to debug and understand where your
requests are handled.

But the main advantage is that (potentially) this will require no coding at
all.

2015-10-02 16:04 GMT+02:00 Lucas Lobosque <lucas.lobosque@contentools.com.br
>:

> I want to do this because we are currently using Tastypie
> <https://github.com/django-tastypie/django-tastypie> to write our API,
> but it is getting to a point where performance is starting to be a problem.
>
> The reason I want to share a codebase is that I have a lot of my
> application logic implemented in the model layer, and switching the API
> layer from tastypie to falcon would greatly improve our application
> performance.
> Then, after this first step, we would also get rid of django and use an
> ORM-only solution for our model layer. (It wouldn't make sense to use
> django if we are only using its ORM).
>
> If I manage to route the requests from falcon to django, we can port the
> whole thing gradually.
>
> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org> wrote:
>
>> Without knowing your exact environment constraints, here is my suggestion:
>>
>> I'd add something like nginx in front of all of it and defining two
>> upstreams, then letting routing rules in nginx determine what goes where.
>> This makes it super easy to define and manage (and reason about) where
>> traffic goes.
>> Then run django and falcon as two seperate servers (locally on different
>> ports, or actually on seperate servers, depending on the case).
>> I don't see any benefit in doing it from code. :)
>>
>> If that solution won't fit for some reason or the other, let me know and
>> I'll try to explain how you could do it from code.
>>
>>
>>
>>
>>
>>
>> Cheers,
>> Henrik Tudborg
>> Tlf.:    (+45) 51 71 99 39
>> www.: tudb.org
>>
>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>> lucas.lobosque@contentools.com.br>:
>>
>>> Hello guys,
>>>
>>> I am using uwsgi as the server and I wonder if it's possible to
>>> implement a catch-all fallback that will route any request that isn't
>>> registered in falcon to Django.
>>> I want to do that in order to gradually port a system to falcon.
>>> Any advise?
>>> Thanks.
>>>
>>
>>
>

Re: [falcon] Django as a fallback for Falcon

From:
James Errico
Date:
2015-10-02 @ 14:29
Are you sure the the performance constraint is from the Django
request\response overhead?  There's no doubt that Falcon offers a
performance edge over Django there, but if the bottleneck is in the app
logic you've mentioned (inefficient ORM\SQL calls for example) you might
not get much improvement.

Just curious, because having worked with Django I've seen some fairly
inefficient ORM\SQL logic pretty frequently.

Thanks,
-James

On Fri, Oct 2, 2015 at 10:04 AM, Lucas Lobosque <
lucas.lobosque@contentools.com.br> wrote:

> I want to do this because we are currently using Tastypie
> <https://github.com/django-tastypie/django-tastypie> to write our API,
> but it is getting to a point where performance is starting to be a problem.
>
> The reason I want to share a codebase is that I have a lot of my
> application logic implemented in the model layer, and switching the API
> layer from tastypie to falcon would greatly improve our application
> performance.
> Then, after this first step, we would also get rid of django and use an
> ORM-only solution for our model layer. (It wouldn't make sense to use
> django if we are only using its ORM).
>
> If I manage to route the requests from falcon to django, we can port the
> whole thing gradually.
>
> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org> wrote:
>
>> Without knowing your exact environment constraints, here is my suggestion:
>>
>> I'd add something like nginx in front of all of it and defining two
>> upstreams, then letting routing rules in nginx determine what goes where.
>> This makes it super easy to define and manage (and reason about) where
>> traffic goes.
>> Then run django and falcon as two seperate servers (locally on different
>> ports, or actually on seperate servers, depending on the case).
>> I don't see any benefit in doing it from code. :)
>>
>> If that solution won't fit for some reason or the other, let me know and
>> I'll try to explain how you could do it from code.
>>
>>
>>
>>
>>
>>
>> Cheers,
>> Henrik Tudborg
>> Tlf.:    (+45) 51 71 99 39
>> www.: tudb.org
>>
>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>> lucas.lobosque@contentools.com.br>:
>>
>>> Hello guys,
>>>
>>> I am using uwsgi as the server and I wonder if it's possible to
>>> implement a catch-all fallback that will route any request that isn't
>>> registered in falcon to Django.
>>> I want to do that in order to gradually port a system to falcon.
>>> Any advise?
>>> Thanks.
>>>
>>
>>
>

Re: [falcon] Django as a fallback for Falcon

From:
Ben Meyer
Date:
2015-10-02 @ 14:34
Sounds like you may want to use the add_sink() functionality...

http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink

That at least seems to be a portion of the functionality you need...

$0.02

Ben

On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
> I want to do this because we are currently using Tastypie
> <https://github.com/django-tastypie/django-tastypie> to write our API,
> but it is getting to a point where performance is starting to be a
> problem.
>
> The reason I want to share a codebase is that I have a lot of my
> application logic implemented in the model layer, and switching the
> API layer from tastypie to falcon would greatly improve our
> application performance.
> Then, after this first step, we would also get rid of django and use
> an ORM-only solution for our model layer. (It wouldn't make sense to
> use django if we are only using its ORM).
>
> If I manage to route the requests from falcon to django, we can port
> the whole thing gradually.
>
> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org
> <mailto:henrik@tudb.org>! > wrote:
>
>     Without knowing your exact environment constraints, here is my
>     suggestion:
>
>     I'd add something like nginx in front of all of it and defining
>     two upstreams, then letting routing rules in nginx determine what
>     goes where.
>     This makes it super easy to define and manage (and reason about)
>     where traffic goes.
>     Then run django and falcon as two seperate servers (locally on
>     different ports, or actually on seperate servers, depending on the
>     case).
>     I don't see any benefit in doing it from code. :)
>
>     If that solution won't fit for some reason or the other, let me
>     know and I'll try to explain how you could do it from code.
>
>
>
>
>
>
>     Cheers,
>     Henrik Tudborg
>     Tlf.:    (+45) 51 71 99 39 <tel:%28%2B45%29%2051%2071%2099%2039>
>     www.: tudb.org <http://tudb.org>
>
>     2015-10-02 15:41 GMT+02:00 Lucas Lobosque
>     <lucas.lobosque@contentools.com.br
>     <mailto:lucas.lobosque@contentools.com.br>>:
>
>         Hello guys,
>
>         I am using uwsgi as the server and I wonder if it's possible
>         to implement a catch-all fallback that will route any request
>         that isn't registered in falcon to Django.
>         I want to do that in order to gradually port a system to falcon.
>         Any advise?
>         Thanks.
>
>
>

Re: [falcon] Django as a fallback for Falcon

From:
Lucas Lobosque
Date:
2015-10-02 @ 14:43
Our performance constraint right now is the Tastypie framework, not the ORM.
I also agree that routing the requests using nginx will be easier to
implement. But doing at the code level will give us way more flexibility to
gradually port our code.
The API layer won't be costly to re-implement, and is not performant.
The ORM/Model layer will take much more time to implement, and has an "ok"
performance. That's why I want to use falcon with django.

On Fri, Oct 2, 2015 at 11:34 AM, Ben Meyer <ben.meyer@rackspace.com> wrote:

> Sounds like you may want to use the add_sink() functionality...
>
> http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink
>
> That at least seems to be a portion of the functionality you need...
>
> $0.02
>
> Ben
>
> On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
>
> I want to do this because we are currently using Tastypie
> <https://github.com/django-tastypie/django-tastypie> to write our API,
> but it is getting to a point where performance is starting to be a problem.
>
> The reason I want to share a codebase is that I have a lot of my
> application logic implemented in the model layer, and switching the API
> layer from tastypie to falcon would greatly improve our application
> performance.
> Then, after this first step, we would also get rid of django and use an
> ORM-only solution for our model layer. (It wouldn't make sense to use
> django if we are only using its ORM).
>
> If I manage to route the requests from falcon to django, we can port the
> whole thing gradually.
>
> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org! > wrote:
>
>> Without knowing your exact environment constraints, here is my suggestion:
>>
>> I'd add something like nginx in front of all of it and defining two
>> upstreams, then letting routing rules in nginx determine what goes where.
>> This makes it super easy to define and manage (and reason about) where
>> traffic goes.
>> Then run django and falcon as two seperate servers (locally on different
>> ports, or actually on seperate servers, depending on the case).
>> I don't see any benefit in doing it from code. :)
>>
>> If that solution won't fit for some reason or the other, let me know and
>> I'll try to explain how you could do it from code.
>>
>>
>>
>>
>>
>>
>> Cheers,
>> Henrik Tudborg
>> Tlf.:    (+45) 51 71 99 39 <%28%2B45%29%2051%2071%2099%2039>
>> www.: tudb.org
>>
>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>> <lucas.lobosque@contentools.com.br>lucas.lobosque@contentools.com.br>:
>>
>>> Hello guys,
>>>
>>> I am using uwsgi as the server and I wonder if it's possible to
>>> implement a catch-all fallback that will route any request that isn't
>>> registered in falcon to Django.
>>> I want to do that in order to gradually port a system to falcon.
>>> Any advise?
>>> Thanks.
>>>
>>
>>
>
>

Re: [falcon] Django as a fallback for Falcon

From:
Henrik Tuborg
Date:
2015-10-02 @ 15:00
There is nothing keeping you from reusing the same python modules in both
places, but still keep it as seperate servers.
I havn't tried to do this with django before, but I can't think of any part
that prevents you from using it.

The alternative is to do all of it from code.
What I'd then suggest, is that you build a tiny WSGI application that your
server sends requests to. This tiny application is then
responsible for defining routing rules to either the falcon or django WSGI
application (pretty much the same aproach as with nginx, but now everything
can be thought about as the "same" WSGI application)

Depending on the complexity of your routing rules, you can either build it
by hand (luckily, WSGI is easy), or use something like
https://github.com/ericmoritz/wsgirouter (I have no experience with that
project, but it looks like it fits the bill)




Cheers,
Henrik Tudborg
Tlf.:    (+45) 51 71 99 39
www.: tudb.org

2015-10-02 16:43 GMT+02:00 Lucas Lobosque <lucas.lobosque@contentools.com.br
>:

> Our performance constraint right now is the Tastypie framework, not the
> ORM.
> I also agree that routing the requests using nginx will be easier to
> implement. But doing at the code level will give us way more flexibility to
> gradually port our code.
> The API layer won't be costly to re-implement, and is not performant.
> The ORM/Model layer will take much more time to implement, and has an "ok"
> performance. That's why I want to use falcon with django.
>
> On Fri, Oct 2, 2015 at 11:34 AM, Ben Meyer <ben.meyer@rackspace.com>
> wrote:
>
>> Sounds like you may want to use the add_sink() functionality...
>>
>> http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink
>>
>> That at least seems to be a portion of the functionality you need...
>>
>> $0.02
>>
>> Ben
>>
>> On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
>>
>> I want to do this because we are currently using Tastypie
>> <https://github.com/django-tastypie/django-tastypie> to write our API,
>> but it is getting to a point where performance is starting to be a problem.
>>
>> The reason I want to share a codebase is that I have a lot of my
>> application logic implemented in the model layer, and switching the API
>> layer from tastypie to falcon would greatly improve our application
>> performance.
>> Then, after this first step, we would also get rid of django and use an
>> ORM-only solution for our model layer. (It wouldn't make sense to use
>> django if we are only using its ORM).
>>
>> If I manage to route the requests from falcon to django, we can port the
>> whole thing gradually.
>>
>> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org! > wrote:
>>
>>> Without knowing your exact environment constraints, here is my
>>> suggestion:
>>>
>>> I'd add something like nginx in front of all of it and defining two
>>> upstreams, then letting routing rules in nginx determine what goes where.
>>> This makes it super easy to define and manage (and reason about) where
>>> traffic goes.
>>> Then run django and falcon as two seperate servers (locally on different
>>> ports, or actually on seperate servers, depending on the case).
>>> I don't see any benefit in doing it from code. :)
>>>
>>> If that solution won't fit for some reason or the other, let me know and
>>> I'll try to explain how you could do it from code.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>> Henrik Tudborg
>>> Tlf.:    (+45) 51 71 99 39 <%28%2B45%29%2051%2071%2099%2039>
>>> www.: tudb.org
>>>
>>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>>> <lucas.lobosque@contentools.com.br>lucas.lobosque@contentools.com.br>:
>>>
>>>> Hello guys,
>>>>
>>>> I am using uwsgi as the server and I wonder if it's possible to
>>>> implement a catch-all fallback that will route any request that isn't
>>>> registered in falcon to Django.
>>>> I want to do that in order to gradually port a system to falcon.
>>>> Any advise?
>>>> Thanks.
>>>>
>>>
>>>
>>
>>
>

Re: [falcon] Django as a fallback for Falcon

From:
Lucas Lobosque
Date:
2015-10-02 @ 15:07
Thanks for the suggestion, Henrik.
Can you point me to any documentation/example that might help? I don't have
a lot of experience with WGSI and I couldn't find any resource that might
help me to "manually" route a request to django (or falcon, by the way)

On Fri, Oct 2, 2015 at 12:00 PM, Henrik Tuborg <henrik@tudb.org> wrote:

> There is nothing keeping you from reusing the same python modules in both
> places, but still keep it as seperate servers.
> I havn't tried to do this with django before, but I can't think of any
> part that prevents you from using it.
>
> The alternative is to do all of it from code.
> What I'd then suggest, is that you build a tiny WSGI application that your
> server sends requests to. This tiny application is then
> responsible for defining routing rules to either the falcon or django WSGI
> application (pretty much the same aproach as with nginx, but now everything
> can be thought about as the "same" WSGI application)
>
> Depending on the complexity of your routing rules, you can either build it
> by hand (luckily, WSGI is easy), or use something like
> https://github.com/ericmoritz/wsgirouter (I have no experience with that
> project, but it l ooks like it fits the bill)
>
>
>
>
> Cheers,
> Henrik Tudborg
> Tlf.:    (+45) 51 71 99 39
> www.: tudb.org
>
> 2015-10-02 16:43 GMT+02:00 Lucas Lobosque <
> lucas.lobosque@contentools.com.br>:
>
>> Our performance constraint right now is the Tastypie framework, not the
>> ORM.
>> I also agree that routing the requests using nginx will be easier to
>> implement. But doing at the code level will give us way more flexibility to
>> gradually port our code.
>> The API layer won't be costly to re-implement, and is not performant.
>> The ORM/Model layer will take much more time to implement, and has an
>> "ok" performance. That's why I want to use falcon with django.
>>
>> On Fri, Oct 2, 2015 at 11:34 AM, Ben Meyer &l t;ben.meyer@rackspace.com>
>> wrote:
>>
>>> Sounds like you may want to use the add_sink() functionality...
>>>
>>> http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink
>>>
>>> That at least seems to be a portion of the functionality you need...
>>>
>>> $0.02
>>>
>>> Ben
>>>
>>> On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
>>>
>>> I want to do this because we are currently using Tastypie
>>> <https://github.com/django-tastypie/django-tastypie> to write our API,
>>> but it is getting to a point where performance is starting to be a problem.
>>>
>>> The reason I want to share a codebase is that I have a lot of my
>>> application logic implemented in the model layer, and switching the API
>>> layer from tastypie to falcon would greatly improve our application
>>> performance.
>>> Then, after this first step, we would also get rid of django and use an
>>> ORM-only solution for our model layer. (It wouldn't make sense to use
>>> django if we are only using its ORM).
>>>
>>> If I manage to route the requests from falcon to django, we can port the
>>> whole thing gradually.
>>>
>>> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org! >
>>> wrote:
>>>
>>>> Without knowing your exact environment constraints, here is my
>>>> suggestion:
>>>>
>>>> I'd add something like nginx in front of all of it and defining two
>>>> upstreams, then letting routing rules in nginx determine what goes where.
>>>> This makes it super easy to define and manage (and reason about) where
>>>> traffic goes.
>>>> Then run django and falcon as two seperate servers (locally on
>>>> different ports, or actually on seperate servers, depending on the case).
>>>> I don't see any benefit in doing it from code. :)
>>>>
>>>> If that solution won't fit for some reason or the other, let me know
>>>> and I'll try to explain how you could do it from code.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Henrik Tudborg
>>>> Tlf.:    (+45) 51 71 99 39 <%28%2B45%29%2051%2071%2099%2039>
>>>> www.: tudb.org
>>>>
>>>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>>>> <lucas.lobosque@contentools.com.br>lucas.lobosque@contentools.com.br>:
>>>>
>>>>> Hello guys,
>>>>>
>>>>> I am using uwsgi as the server and I wonder if it's possible to
>>>>> implement a catch-all fallback that will route any request that isn't
>>>>> registered in falcon to Django.
>>>>> I want to do that in order to gradually port a system to falcon.
>>>>> Any advise?
>>>>> Thanks.
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

Re: [falcon] Django as a fallback for Falcon

From:
Henrik Tuborg
Date:
2015-10-02 @ 15:25
Sure.
I'll try to go from uWSGI.
First, WSGI basics: a WSGI "application" is just a python callable that
accepts 2 arguments. A Dict with all the information you need about a
request, and a callable for sending the response. This "application"
callable is called for each incomming request.

The uWSGI documentation is actually a good place to start:

https://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#the-first-wsgi-application

Here you see the `env` and `start_response` and how they are used.
This is all there is to it.

Now, the entrypoint for falcon is an instance of the `falcon.API` (it
provides a __call__ that takes, yes, you guessed it, `env` and
`start_response`)

So in falcon, when you say `application = falcon.API()`, you have your WSGI
application.
Same thing in django. You should have a file in your root folder called
`wsgi.py`, containing a variable called `application` (I think. Going from
memory here).

Now, the falcon `application` variable and the Django `application`
variable is both WSGI applications.

What I suggest is that you create your own WSGI application (see the link
to uWSGI above for how that could look) that simply inspects the `env`, and
determines if it should route to the falcon app or the Django app.

Something along the lines of
https://gist.github.com/tbug/2af296c7a47e8fcd4f7c

Now, if you have complex routing rules I suggested looking at
https://github.com/ericmoritz/wsgirouter which pretty much does what you
expect.

Then you could be done with something like
https://gist.github.com/tbug/f71fc0e604a917a22c5b

(Note: neither pieces of code is tested and is only for inspiration)

If you need more on WSGI, read https://www.python.org/dev/peps/pep-3333/
You can also take a look at how falcon receives requests by looking at the
`falcon.API`
class (specifically the `__call__` method)

Falcon's code-base is well-written and filled with good comments, so in any
case I recommend giving it a read.




Cheers,
Henrik Tudborg
Tlf.:    (+45) 51 71 99 39
www.: tudb.org

2015-10-02 17:07 GMT+02:00 Lucas Lobosque <lucas.lobosque@contentools.com.br
>:

> Thanks for the suggestion, Henrik.
> Can you point me to any documentation/example that might help? I don't
> have a lot of experience with WGSI and I couldn't find any resource that
> might help me to "manually" route a request to django (or falcon, by the
> way)
>
> On Fri, Oct 2, 2015 at 12:00 PM, Henrik Tuborg <henrik@tudb.org> wrote:
>
>> There is nothing keeping you from reusing the same python modules in both
>> places, but still keep it as seperate servers.
>> I havn't tried to do this with django before, but I can't think of any
>> part that prevents you from using it.
>>
>> The alternative is to do all of it from code.
>> What I'd then suggest, is that you build a tiny WSGI application that
>> your server sends requests to. This tiny application is then
>> responsible for defining routing rules to either the falcon or django
>> WSGI application (pretty much the same aproach as with nginx, but now
>> everything can be thought about as the "same" WSGI application)
>>
>> Depending on the complexity of your routing rules, you can either build
>> it by hand (luckily, WSGI is easy), or use something like
>> https://github.com/ericmoritz/wsgirouter (I have no experience with that
>> project, but it l ooks like it fits the bill)
>>
>>
>>
>>
>> Cheers,
>> Henrik Tudborg
>> Tlf.:    (+45) 51 71 99 39
>> www.: tudb.org
>>
>> 2015-10-02 16:43 GMT+02:00 Lucas Lobosque <
>> lucas.lobosque@contentools.com.br>:
>>
>>> Our performance constraint right now is the Tastypie framework, not the
>>> ORM.
>>> I also agree that routing the requests using nginx will be easier to
>>> implement. But doing at the code level will give us way more flexibility to
>>> gradually port our code.
>>> The API layer won't be costly to re-implement, and is not performant.
>>> The ORM/Model layer will take much more time to implement, and has an
>>> "ok" performance. That's why I want to use falcon with django.
>>>
>>> On Fri, Oct 2, 2015 at 11:34 AM, Ben Meyer &l t;ben.meyer@rackspace.com>
>>> wrote:
>>>
>>>> Sounds like you may want to use the add_sink() functionality...
>>>>
>>>> http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink
>>>>
>>>> That at least seems to be a portion of the functionality you need...
>>>>
>>>> $0.02
>>>>
>>>> Ben
>>>>
>>>> On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
>>>>
>>>> I want to do this because we are currently using Tastypie
>>>> <https://github.com/django-tastypie/django-tastypie> to write our API,
>>>> but it is getting to a point where performance is starting to be a problem.
>>>>
>>>> The reason I want to share a codebase is that I have a lot of my
>>>> application logic implemented in the model layer, and switching the API
>>>> layer from tastypie to falcon would greatly improve our application
>>>> performance.
>>>> Then, after this first step, we would also get rid of django and use an
>>>> ORM-only solution for our model layer. (It wouldn't make sense to use
>>>> django if we are only using its ORM).
>>>>
>>>> If I manage to route the requests from falcon to django, we can port
>>>> the whole thing gradually.
>>>>
>>>> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org! >
>>>> wrote:
>>>>
>>>>> Without knowing your exact environment constraints, here is my
>>>>> suggestion:
>>>>>
>>>>> I'd add something like nginx in front of all of it and defining two
>>>>> upstreams, then letting routing rules in nginx determine what goes where.
>>>>> This makes it super easy to define and manage (and reason about) where
>>>>> traffic goes.
>>>>> Then run django and falcon as two seperate servers (locally on
>>>>> different ports, or actually on seperate servers, depending on the case).
>>>>> I don't see any benefit in doing it from code. :)
>>>>>
>>>>> If that solution won't fit for some reason or the other, let me know
>>>>> and I'll try to explain how you could do it from code.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Henrik Tudborg
>>>>> Tlf.:    (+45) 51 71 99 39 <%28%2B45%29%2051%2071%2099%2039>
>>>>> www.: tudb.org
>>>>>
>>>>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>>>>> <lucas.lobosque@contentools.com.br>lucas.lobosque@contentools.com.br>:
>>>>>
>>>>>> Hello guys,
>>>>>>
>>>>>> I am using uwsgi as the server and I wonder if it's possible to
>>>>>> implement a catch-all fallback that will route any request that isn't
>>>>>> registered in falcon to Django.
>>>>>> I want to do that in order to gradually port a system to falcon.
>>>>>> Any advise?
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [falcon] Django as a fallback for Falcon

From:
Lucas Lobosque
Date:
2015-10-02 @ 15:31
Thank you Henrik, that's an awesome introduction and enough for me to start
writing some code!

On Fri, Oct 2, 2015 at 12:25 PM, Henrik Tuborg <henrik@tudb.org> wrote:

> Sure.
> I'll try to go from uWSGI.
> First, WSGI basics: a WSGI "application" is just a python callable that
> accepts 2 arguments. A Dict with all the information you need about a
> request, and a callable for sending the response. This "application"
> callable is called for each incomming request.
>
> The uWSGI documentation is actually a good place to start:
>
> 
https://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#the-first-wsgi-application
>
> Here you see the `env` and `start_response` and how they are used.
> This is all there is to it.
>
> Now, the entrypoint for falcon is an instance of the `falcon.API` (it
> provides a __call__ that takes, yes, you guessed it, `env` and
> `start_response`)
>
> So in falcon, when you say `application = falcon.API()`, you have your
> WSGI application.
> Same thing in django. You should have a file in your root folder called
> `wsgi.py`, containing a variable called `application` (I think. Going from
> memory here).
>
> Now, the falcon `application` variable and the Django `application`
> variable is both WSGI applications.
>
> What I suggest is that you create your own WSGI application (see the link
> to uWSGI above for how that could look) that simply inspects the `env`, and
> determines if it should route to the falcon app or the Django app.
>
> Something along the lines of
> https://gist.github.com/tbug/2af296c7a47e8fcd4f7c
>
> Now, if you have complex routing rules I suggested looking at
> https://github.com/ericmoritz/wsgirouter which pretty much does what you
> expect.
>
> Then you could be done with something like
> https://gist.github.com/tbug/f71fc0e604a917a22c5b
>
> (Note: neither pieces of code is tested and is only for inspiration)
>
> If you need more on WSGI, read https://www.python.org/dev/peps/pep-3333/
> You can also take a look at how falcon receives requests by looking at the
> `falcon.API`
> class (specifically the `__call__` method)
>
> Falcon's code-base is well-written and filled with good comments, so in
> any case I recommend giving it a read.
>
>
>
>
> Cheers,
> Henrik Tudborg
> Tlf.:    (+45) 51 71 99 39
> www.: tudb.org
>
> 2015-10-02 17:07 GMT+02:00 Lucas Lobosque <
> lucas.lobosque@contentools.com.br>:
>
>> Thanks for the suggestion, Henrik.
>> Can you point me to any documentation/example that might help? I don't
>> have a lot of experience with WGSI and I couldn't find any resource that
>> might help me to "manually" route a request to django (or falcon, by the
>> way)
>>
>> On Fri, Oct 2, 2015 at 12:00 PM, Henrik Tuborg <henrik@tudb.org> wrote:
>>
>>> There i s nothing keeping you from reusing the same python modules in
>>> both places, but still keep it as seperate servers.
>>> I havn't tried to do this with django before, but I can't think of any
>>> part that prevents you from using it.
>>>
>>> The alternative is to do all of it from code.
>>> What I'd then suggest, is that you build a tiny WSGI application that
>>> your server sends requests to. This tiny application is then
>>> responsible for defining routing rules to either the falcon or django
>>> WSGI application (pretty much the same aproach as with nginx, but now
>>> everything can be thought about as the "same" WSGI application)
>>>
>>> Depending on the complexity of your routing rules, you can either build
>>> it by hand (luckily, WSGI is easy), or use something like
>>> https://github.com/ericmoritz/wsgirouter (I have no experience with
>>> that project, but it l ooks like it fits the bill)
>>>
>>>
>>>
>>>
>>> Cheers,
>>> Henrik Tudborg
>>> Tlf.:    (+45) 51 71 99 39
>>> www.: tudb.org
>>>
>>> 2015-10-02 16:43 GMT+02:00 Lucas Lobosque <
>>> lucas.lobosque@contentools.com.br>:
>>>
>>>> Our performance constraint right now is the Tastypie framework, not the
>>>> ORM.
>>>> I also agree that routing the requests using nginx will be easier to
>>>> implement. But doing at the code level will give us way more flexibility to
>>>> gradually port our code.
>>>> The API layer won't be costly to re-implement, and is not performant.
>>>> The ORM/Model layer will take much more time to implement, and has an
>>>> "ok" performance. That's why I want to use falcon with django.
>>>> < br>
>>>> On Fri, Oct 2, 2015 at 11:34 AM, Ben Meyer &l t;ben.meyer@rackspace.com
>>>> > wrote:
>>>>
>>>>> Sounds like you may want to use the add_sink() functionality...
>>>>>
>>>>>
>>>>> http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink
>>>>>
>>>>> That at least seems to be a portion of the functionality you need...
>>>>>
>>>>> $0.02
>>>>>
>>>>> Ben
>>>>>
>>>>> On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
>>>>>
>>>>> I want to do this because we are currently using Tastypie
>>>>> <https://github.com/django-tastypie/django-tastypie> to write our
>>>>> API, but it is getting to a point where performance is starting to be a
>>>>> problem.
>>>>>
>>>>> The reason I want to share a codebase is that I have a lot of my
>>>>> application logic implemented in the model layer, and switching the API
>>>>> layer from tastypie to falcon would greatly improve our application
>>>>> performance.
>>>>> Then, after this first step, we would also get rid of django and use
>>>>> an ORM-only solution for our model layer. (It wouldn't make sense to use
>>>>> django if we are only using its ORM).
>>>>>
>>>>> If I manage to route the requests from falcon to django, we can port
>>>>> the whole thing gradually.
>>>>>
>>>>> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org! >
>>>>> wrote:
>>>>>
>>>>>> Without knowing your exact environment constraints, here is my
>>>>>> suggestion:
>>>>>>
>>>>>> I'd add something like nginx in front of all of it and defining two
>>>>>> upstreams, then letting routing rules in nginx determine what goes where.
>>>>>> This makes it super easy to define and manage (and reason about)
>>>>>> where traffic goes.
>>>>>> Then run django and falcon as two seperate servers (locally on
>>>>>> different ports, or actually on seperate servers, depending on the case).
>>>>>> I don't see any benefit in doing it from code. :)
>>>>>>
>>>>>> If that solution won't fit for some reason or the other, let me know
>>>>>> and I'll try to explain how you could do it from code.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Henrik Tudborg
>>>>>> Tlf.:    (+45) 51 71 99 39 <%28%2B45%29%2051%2071%2099%2039>
>>>>>> www.: tudb.org
>>>>>>
>>>>>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>>>>>> <lucas.lobosque@contentools.com.br>lucas.lobosque@contentools.com.br>
>>>>>> :
>>>>>>
>>>>>>> Hello guys,
>>>>>>>
>>>>>>> I am using uwsgi as the server and I wonder if it's possible to
>>>>>>> implement a catch-all fallback that will route any request that isn't
>>>>>>> registered in falcon to Django.
>>>>>>> I want to do that in order to gradually port a system to falcon.
>>>>>>> Any advise?
>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [falcon] Django as a fallback for Falcon

From:
Ben Meyer
Date:
2015-10-02 @ 16:26
Reading over Henrik's response, there is actually a little nicer
approach you could take - using WSGI Middleware.
This is basically a wrapper that adds functionality, or can even do
routing between two different WSGI apps on a per-request basis.

For example, the EOM project has a Bastion middleware that can be used
to route between (or around) other components in the stack; see
http://eom.readthedocs.org/en/latest/api/bastion.html. It's usually used
to route around auth for special end-points. You could do a similar
trick to route between the Falcon-based app and the Tastypie-base app.

HTH,

Ben

P.S resending b/c first time got rejected by mailing list due to size
(?). Sorry if you get duplicates.

On 10/02/2015 11:31 AM, Lucas Lobosque wrote:
> Thank you Henrik, that's an awesome introduction and enough for me to
> start writing some code!
>
> On Fri, Oct 2, 2015 at 12:25 PM, Henrik Tuborg <henrik@tudb.org
> <mailto:henrik@tudb.org>> wrote:
>
>     Sure.
>     I'll try to go from uWSGI.
>     First, WSGI basics: a WSGI "application" is just a python callable
>     that accepts 2 arguments. A Dict with all the information you need
>     about a request, and a callable for sending the response. This
>     "application" callable is called for each incomming request.
>
>     The uWSGI documentation is actually a good place to start:
>     https://uws! gi-docs.r
>     eadthedocs.org/en/latest/WSGIquickstart.html#the-first-wsgi-application
>     
<https://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html#the-first-wsgi-application>
>
>     Here you see the `env` and `start_response` and how they are used.
>     This is all there is to it.
>
>     Now, the entrypoint for falcon is an instance of the `falcon.API`
>     (it provides a __call__ that takes, yes, you guessed it, `env` and
>     `start_response`)
>
>     So in falcon, when you say `application = falcon.API()`, you have
>     your WSGI application.
>     Same thing in django. You should have a file in your root folder
>     called `wsgi.py`, containing a variable called `application` (I
>     think. Going from memory here).
>
>     Now, the falcon `application` variable and the Django
>     `application` variable is both WSGI applications.
>
>     What I suggest is that you create your own WSGI application (see
>     the link to uWSGI above for how that could look) that simply
>     inspects the `env`, and determines if it should route to the
>     falcon app or the Django app.
>
>     Something along the lines
>     of https://gist.github.com/tbug/2af296c7a47e8fcd4f7c
>
>     Now, if you have complex routing rules I suggested looking
>     at https://github.com/ericmoritz/wsgirouter which pretty much does
>     what you expect.
>     < br>
>     Then you could be done with something
>     like https://gist.github.com/tbug/f71fc0e604a917a22c5b
>
>     (Note: neither pieces of code is tested and is only for inspiration)
>
>     If you need more on WSGI,
>     read https://www.python.org/dev/peps/pep-3333/
>     You can also take a look at how falcon receives requests by
>     looking at the `falcon.API`
>     class (specifically the `__call__` method)
>
>     Falcon's code-base is well-written and filled with good comments,
>     so in any case I recommend giving it a read.
>
>     2015-10-02 17:07 GMT+02:00 Lucas Lobosque
>     <lucas.lobosque@contentools.com.br>:
>
>         Thanks for the suggestion, Henrik.
>         Can you point me to any documentation/example that might help?
>         I don't have a lot of experience with WGSI and I couldn't find
>         any resource that might help me to "manually" route a request
>         to django (or falcon, by the way)
>
>         On Fri, Oct 2, 2015 at 12:00 PM, Henrik Tuborg
>         <henrik@tudb.org> wrote:
>
>             There i s nothing keeping you from reusing the same python
>             modules in both places, but still keep it as seperate servers.
>             I havn't tried to do this with django before, but I can't
>             think of any part that prevents you from using it.
>
>             The alternative is to do all of it from code.
>             What I'd then suggest, is that you build a tiny WSGI
>             application that your server sends requests to. This tiny
>             application is then
>             responsible for defining routing rules to either the
>             falcon or django WSGI application (pretty much the same
>             aproach as with nginx, but now everything can be thought
>             about as the "same" WSGI application)
>
>             Depending on the complexity of your routing rules, you can
>             either build it by hand (luckily, WSGI is easy), or use
>             something like https://github.com/ericmoritz/wsgirouter (I
>             have no experience with that project, but it l ooks like
>             it fits the bill)
>

Re: [falcon] Django as a fallback for Falcon

From:
James Errico
Date:
2015-10-02 @ 14:53
Got it Lucas, thanks for clarifying.  Are the two systems going to run on
different ports?  I've never tried binding both Falcon and Django the same
port before...I kind of feel like that might introduce a conflict but
admittedly I'm basing that off of nothing more than a feeling.

On Fri, Oct 2, 2015 at 10:43 AM, Lucas Lobosque <
lucas.lobosque@contentools.com.br> wrote:

> Our performance constraint right now is the Tastypie framework, not the
> ORM.
> I also agree that routing the requests using nginx will be easier to
> implement. But doing at the code level will give us way more flexibility to
> gradually port our code.
> The API layer won't be costly to re-implement, and is not performant.
> The ORM/Model layer will take much more time to implement, and has an "ok"
> performance. That's why I want to use falcon with django.
>
> On Fri, Oct 2, 2015 at 11:34 AM, Ben Meyer <ben.meyer@rackspace.com>
> wrote:
>
>> Sounds like you may want to use the add_sink() functionality...
>>
>> http://falcon.readthedocs.org/en/stable/api/api.html#falcon.API.add_sink
>>
>> That at least seems to be a portion of the functionality you need...
>>
>> $0.02
>>
>> Ben
>>
>> On 10/02/2015 10:04 AM, Lucas Lobosque wrote:
>>
>> I want to do this because we are currently using Tastypie
>> <https://github.com/django-tastypie/django-tastypie> to write our API,
>> but it is getting to a point where performance is starting to be a problem.
>>
>> The reason I want to share a codebase is that I have a lot of my
>> application logic implemented in the model layer, and switching the API
>> layer from tastypie to falcon would greatly improve our application
>> performance.
>> Then, after this first step, we would also get rid of django and use an
>> ORM-only solution for our model layer. (It wouldn't make sense to use
>> django if we are only using its ORM).
>>
>> If I manage to route the requests from falcon to django, we can port the
>> whole thing gradually.
>>
>> On Fri, Oct 2, 2015 at 10:55 AM, Henrik Tuborg <henrik@tudb.org! > wrote:
>>
>>> Without knowing your exact environment constraints, here is my
>>> suggestion:
>>>
>>> I'd add something like nginx in front of all of it and defining two
>>> upstreams, then letting routing rules in nginx determine what goes where.
>>> This makes it super easy to define and manage (and reason about) where
>>> traffic goes.
>>> Then run django and falcon as two seperate servers (locally on different
>>> ports, or actually on seperate servers, depending on the case).
>>> I don't see any benefit in doing it from code. :)
>>>
>>> If that solution won't fit for some reason or the other, let me know and
>>> I'll try to explain how you could do it from code.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>> Henrik Tudborg
>>> Tlf.:    (+45) 51 71 99 39 <%28%2B45%29%2051%2071%2099%2039>
>>> www.: tudb.org
>>>
>>> 2015-10-02 15:41 GMT+02:00 Lucas Lobosque <
>>> <lucas.lobosque@contentools.com.br>lucas.lobosque@contentools.com.br>:
>>>
>>>> Hello guys,
>>>>
>>>> I am using uwsgi as the server and I wonder if it's possible to
>>>> implement a catch-all fallback that will route any request that isn't
>>>> registered in falcon to Django.
>>>> I want to do that in order to gradually port a system to falcon.
>>>> Any advise?
>>>> Thanks.
>>>>
>>>
>>>
>>
>>
>