It sounds like the only true way of solving this "cleanly" is to be able to use Channels to communicate with the user's web browser as well, which right now means WebSockets (one of the things I want to look at this year is Channels support for something like socket.io/sock.js which has a polling fallback as well).
Given you can't do that as you're using AJAX, you'll have to do your own buffering and queuing, and so a database table is probably the least bad way. I would suggest re-using parts of django sessions (e.g. session key) for identification of the users rather than re-inventing that.
It's not going to be hugely scalable, but it should do well enough and it sounds like your Django interactions are not super common anyway. Just make sure you plan around what to do when a message does not come back (retry? show failure?) and that you clear old messages out from the storage that were not consumed, e.g. if the user closed the browser before the response was read.
You could also try using the low-level ASGI API and make your own channels to store and buffer these messages and then use non-blocking channel_layer.receive_many(), but that's a bit more complex and I don't want to recommend it if it's basically just adding complexity without much benefit (it would save you doing database stuff and expiry, not sure if that's worth it for you or not)
Andrew
On Thu, Dec 29, 2016 at 4:16 PM, Ken McDonald <publicpostemail@gmail.com> wrote:
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:--Q) Are the websocket and the AJAX calls going to different clients/pages entirely, rather than them both being in the same page context? It sounds like the websocket is going to a server somewhere that's allocating resources and not going to a webpage/browser at all.A) Currently the websockets are used in a background system running on Django and most of the use for websockets on this service are so the remote system we are interfacing with can pull a list of subscribers from a Django model and then the remote system does uncoordinated stuff with that. Occasionally, the remote system updates data to Django models for debugging information or sending statistics back.
In the normal course of the application, the web server web page interface is between user and Django model and has no need for a direct connection to the remote system through websockets; they are just setting up subscription types as a seller or buying subscriptions as a buyer. Later, when they are using the remote system, which happens with a completely different client native compiled application, not Django or web interface, they make use of the real purpose of our system which is enhanced by the subscriptions we sell. Basically, we
are using the Django web service to sell subscriptions which are then periodically download through websockets to a remote native compiled application.
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:Q) - Could it potentially take the websocket client that is sending the LOBBY data back that needs to then be conveyed over AJAX some time to reply? Say, more than ten seconds?A) The return replies are just about instantaneous and very small in size. Although ultimately the system will interface with potentially 1000's of distinct remote systems, the Django web service is only used for a very, very short period of time by a user, and then maybe never again if they just continue to renew their subscription. The users are at the remote systems. We just sell stuff that makes that experience better. The need for displaying return data as envisioned in my original question is a rare occurannce almost exclusively used by sellers and more so, just by administrators of the system.
On Thursday, December 29, 2016 at 6:00:03 AM UTC-5, Andrew Godwin wrote:Q) I think I have an idea of what you're trying to do here and how to solve it, but I just need to be a bit more clear on the architecture first.
A) My primary purpose for the django-channels to remote system is working great. I can download from a model and upload to a model through websockets (just for reference: the interface at the remote system is a C++ compiled application (w/ websockets) connected to a C# final product).
There are various need, by this example can best describe a single feature:
1) We have a debugging system on the remote system that will upload transactions from there to our Django model through websockets.
2) In that debugging system, we can set various levels of verbosity to control how much detail is returned.
3) I have a working Django web page now that can send commands that change the debugging level through a websocket-routed command in a JSON message with a particular debugging level (like 1-7). This web page uses a Django template with a radio button form for the 1-7 choices.
4) When a choice is changed on the form, Javascript catches it and calls a Django function that send the websocket command to the remote system to change the debugging (we track websocket instances of channel names in a database, so I can always contact a particular remote system by knowing our own internally-assign db id to lookup the Django channel name for that websocket connection).
In the above example, what I am looking for is that when the web page is initially rendered (url'd in browser), fetch the current debugging level from the remote system and pre-set the radio buttons. Right now of course, the page just renders with a default layout of the radio button without reference to what the current debugging level actually is at the remote site.
In addition to the websocket JSON command to tell the remote system to set a particular debugging level, I also have a command that requests the current debugging level. It's connecting the reply back data from that request command to the webpage when it's initially rendered that is proving difficult to understand.
Thanks for any help you or anyone can provide. I'm dealing with a lot of technologies and a lot of languages that I'm not totally expert or experienced with, but I will complete this project in one form or another. My system engineering background leads me to want a design that is more push and event-driven, than pull and polling. I can find a solution that is pull and polling (store in table, Javascript timed refresh from table), but I find the lack of immediacy of results and slushiness of current data with that strategy to be less than ideal.
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+unsubscribe@googlegroups.com .
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/df5d9d35- .ac42-4e74-b948-23d4e9badb52% 40googlegroups.com
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFwN1urfEvhCYu%2BmS710HYS5GKA__kS0_POXSds3HgLK7TVWQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment