I am making a website with django now and I want to implement a live notification feature like the one on facebook or SE.
I did some research and it seems although there's two options: ajax long polling and websockets, the latter is the way to go.
However, as you know the go to plugin for websocket 'socket.io' turns out to be a node.js plugin and the django port only seems to support python 2 and the project seems pretty much dead. I am using python 2.7 as my project interpreter but I want to future proof myself so that if I upgrade to python3 later, I don't find myself not being able to use this functionality.
So my question is this:
Is there a straight forward and future ready way to implement websocket which will be used to send live notifications and chats in django env?
Django itself is build in blocking manner, i.e. with synchronous approach. So, you cannot open persistent websocket with django app, as it will block entire django thread.
If you want to enable notification/chat within django project environment, i would recommend to use centrifuge. It is written in python, but async (non-blocking) framework is used: tornado.
But, you don't need to even know how it works, as it provides simple REST api to communicate with it.
Simplified workflow, check docs for more details:
Start centrifuge at same server, as your django project (or on another but with low latency between them)
Your front-end will open websocket with centrifuge, not with django project.
When you need to send notification, send it to centrifuge from django via REST api, and centrifuge will deliver it to needed clients!
I've already tried it and it works!
Django doesn't provide what you're looking for out of the box. You'll have to use a third party library. One that works across frameworks is Pusher.
I think you must go for Firebase it gives you awesome synchronization and any how you are going to use chat on frontend so its does not have to do anything with django environment so you can update you backend asynchron in callback with firbase. Also firebase with AngularJS provides you really really awesome three way binding.
Related
I am currently working on a django project where I need a separate backend application to be able to initiate gRPC requests to my django frontend.
Simply put: I want the backend to be able to access and change objects.
Therefore I need my django project to also start my grpc server while starting up.
I did a lot of research and didn't really find any best practice on that.
As far as I would imagine, I could override the startup command of django to also start my grpc server on a seperate thread. But I am afraid that I will end up with a very bad practice solution.
Is there any recommendable way to do this?
I am excited about every hint :)
So I have a basic question about WebRTC with Python Django.
Maybe I start at the beginning:
So is it possible that Python Django can serve as a Server for WebRTC? I think in generell it shouldn't be that hard, because how I saw the WebRTC client only needs a Websocket connection. I hope anybody can help me with that. Btw. I use Django Channels, so I think it is possible to build this connection, but how? :)
I would guess they're not recommending it above because it gets complicated very quickly implementing WebRTC video calls on your own with cross-browser support (Safari, especially). Using existing video APIs that have done that work for you can be a great option for a lot of companies to avoid all the edge cases that affect video quality. Daily, Agora, Twilio are all video API options that can handle this work for you.
It's not impossible but I do not recommend!
Instead, there are some WebRTC media servers like Jitsi, AntMedia and Janus. I used the last one on one of our project with Django.
Checkout microservices achitecture and find a way to combine your project with Django (for Authentication, Authorization and other processes) + WebRTC Media Server + Frontend and/or Mobile App. May Frontend could be in same code base with Django, up to you.
I'm currently working on a project which would require some realtime functionalities such as Multi-user chatrooms etc.
Ideally, I’m looking to have meteor run the chat application(on a different port) and mongodb act as message broker to the django back-end which would take care of user registration , management and everything 'non-realtime' related.
This would involve setting up a reverse-proxy which would redirect to a different port based on the url (please let me know if i'm wrong in this)
Would this be possible(or even advisable)? Another option would be to implement the same with tornado. but I have no experience with building tornado-based apps and rather do this with a framework I’m comfortable with.
Thanks,
You can have Django serve the Meteor front-end while providing access to its data using django-ddp, giving you some distinct advantages:
Continue to serve your existing Django project/apps.
No extra services or ports to manage.
Scale out by simply adding more front-end Python/Django servers (server to server IPC is done via the existing database connection).
Use django.contrib.auth user accounts in your Meteor app.
Familiar Python/Django code (no "callback" style such as with Tornado).
Use time-tested, trusted relational databases.
Use Django migrations to effectively manage schema changes.
There's a Gitter chat room where I can give you assistance if you need it.
DISCLAIMER: I'm the author of django-ddp.
A meteor application is more than capable of handling the user registration flow and many other things. Why not just build the application entirely in meteor? Your application sounds like a perfect candidate for meteor, with realtime interaction with your database at the core.
The other option would be to use swampdragon which adds realtime data binding within django. It allows for simple bi directional communication between the server and the client. Again, essential for a chat application. It nice and easy to get setup and running as well.
Are there any specific reasons to not implementing your application in one framework alone?
A client talks to Django, and django uses node.js to do some javascript related work to give back the client a http response.
I wonder how I should set up the link(?) between the django and node.js.
Simply, I could use python's requests library and talk http, but is this best I can do?
If I were to build the communication link in c++, I would create non-block socket with Send/Recv Thread and use mutex(or similar) between the django view code and the send/recv thread.
I guess that's what is called asynchronous io in node.js world.
Is there a similar thing in python so that I could use on django side to talk to another server?
I heard many big companies use Thrift, would it fit here?
I also see gevent might be relevant keyword here, but not sure.
I am not sure if my answer is still relevant, but I'll give it a try.
IMHO, the best solution for you would be to have a RESTful API for your Django app. This has several advantages:
it provides a lot of decoupling between your Django app and your Node.js one, so in case you ever want to reuse any of them or to replace one of them, it will be easy
it allows you to design an API for each of them and to hide the rest of your implementation (your Django app should not care how Node.js does its job, but only the response that it provides)
there are many great frameworks out there that can help you quickly build your APIs (at leat for Django there is Django REST framework)
If you don't want to build a RESTful API, python's request library is probably the best and easiest way.
Good luck.
I've a huge django project and have to use Instagram API and its subscriptions model to work. For the subscriptions, my server has to be very responsive and be ready to work asynchronously to set up a hook so as to receive notifications once the user posts. Or that's what the documentation suggests. Now will it be a good thing to use Tornado there? Just for that small part or can I do it using Django in an effective way? if so, how?
You can use the WSGI container on top of Tornado to host any WSGI application, including Django, however, when you do that the WSGI application is still running as a blocking application and will not magically be running as an asynchronous application. So, when Django is handling a request there is no ability to handle another request at the same time within Django. The solution at that point is not much different to running a single threaded WSGI server and you would need to have multiple Tornado instances to handle concurrent requests.
So all really depends on what you mean by asynchronous. You certainly can't make use of Tornado's direct asynchronous programming API in Django. Thus there isn't really any great benefit from using Tornado with Django via the WSGI interface.
As I understand you are talking about this paragraph in Instagram docs
You should build your system to accept multiple update objects per payload - though often there will be only one included. Also, you should acknowledge the POST within a 2 second timeout--if you need to do more processing of the received information, you can do so in an asynchronous task.
That's another type of "asynchronous" that Tornado provides.
I think Django + Celery will suite better for this.
Your application will work in this way:
You receive JSON-data from Instagram
Create a celery-task, e.g. instagram_process.delay(request.raw_post_data) or instagram_process.delay(request.body) according to your Django version
Response to Instagram with 200 status code
In instagram_process task you do all your procession - parse JSON, store it do database and anything else you need.
If you want to check X-Hub-Signature you can either do it between steps 1 and 2, or pass this header to the task and verify the signature at step 4.
You can use tornado.wsgi to integrate Tornado with other WSGI compliant frameworks. Check out this demo project for details:
https://github.com/bdarnell/django-tornado-demo