Well your workflow would be following steps roughly:

1) End user requests URL from your Django site
2) Django router URL to a view
3) View code opens remote connection to RESTful service somewhere on the web
4) View code receive response from service
5) Data is processed
6) Data is rendered to end user

Now there is problem in step 3 and 4. That part may take long time
(minutes), what happens if service is down? Request will fail. Now what
happens at end user part? Browser will be waiting for response. Which in
turn connects to a frontend webserver which actually blocks either thread
or process. Now you hit second problem, what if you run for example 20
threads/processes in total. What happens when 21st request is coming in?
Well end user can't access your site at all because it's waiting for 20
older responses to come up.

That's why other people are suggesting that you don't request restful
service (unless you really can guarantee that it's fast) from view code but
do processing outside your web app. Like using background task to retrieve
data in timely manner and store it locally, or actually read that data
directly from the restful service without involving a django view.


If you could describe more of your use case, what data, what nature, why
you want to access it from a view we could give you a more specific help.


On Thu, Nov 5, 2015 at 3:31 AM, kk <krm...@gmail.com> wrote:

>
>
>
> On Wednesday 04 November 2015 10:43 PM, Avraham Serour wrote:
>
>> the question is why, why would you want to store a global connection for
>> a REST server?
>> keep in mind that you would be making HTTP requests, meaning even that
>> you had a global variable holding the connection it would just open and
>> close each tie you make a request.
>>
>
> No, I am not talking about the REST server.
> The REST server is a totally different service and I am just consuming it
> through Django views.
> So I have to use a client connection object such as Python request
> So I want to keep it as global, so that all views can access it from a
> single location, instead of creating a client request instance for every
> view on every call.
>
>
> Happy hacking.
> Krishnakant.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/563AB16E.9060604%40gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHn91ocG3m3VaMKEE2ycamiFX4H6E%2BpiphXgegJyR63qneW12A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to