Can someone clarify the differences or complementarities between Django Channels Project and new Django native async support?
From what I understood, Django-Channels is a project that have been started outside of Django, and then, started to be integrated in the core Django. But the current state of this work remains confusing to me.
For example, today I'm using Django 2.2, and I'd like to add WebSocket support to my project. Should I:
Upgrade to the latest Django version?
Use Django Channels package?
Do both actions?
today I'm using Django 2.2, and I'd like to add WebSocket support to my project.
If you want to add websocket support to your app, at the moment you don't need to upgrade to django 3.0. Django 2.2 plus channels can do that - and for the time being is the best way forward. (Although there's absolutely no harm in upgrading to django 3.0 if you don't have any good reason not to). I will try and further explain why in this answer.
From what I understood, Django-Channels is a project that have been
started outside of Django, and then, started to be integrated in the
core Django. But the current state of this work remains confusing to
me.
Yes, my understanding is that channels started out as a project from one of the core Django developers (Andrew Godwin - who has also been instrumental in bringing about the async changes brought in Django 3.0). It is not included automatically if you just install Django, but it is officially part of the django project, and has been since september 2016 (see here). It's now on version 2.4 and so is an established and stable project that can be used to add websockets to your django app.
So What's going on with Django 3.x and async?
Whilst channels adds a way to add some async functionality to your django app, Django at it's core is still synchonous. The 'async' project that is being gradually introduced addresses this. The key thing to note here is that it's being introduced gradually. Django is made up of several layers:
WSGI server (not actually part of django): deals with the protocol of actually accepting an HTTP request
Base Handler: This takes the request passed to it from the server and makes sure it's sent through the middleware, and the url config, so that we end up with a django request object, and a view to pass it to.
The view layer (which does whatever you tell it to)
The ORM, and all the other lovely stuff you get with Django, that we can call from the view.
Now to fully benefit from async, we really need all of these layers to be async, otherwise there won't really be any performance benefit. This is a fairly big project, hence why it is being rolled out gradually:
With the release of django 3.0, all that was really added was the ability to talk to an ASGI sever, (rather than just a WSGI one).
When Django 3.1 is released (expected august 2020) it is anticipated that there will be capabilities for asynchronous middleware and views.
Then finally in django 3.2, or maybe even 4.0 we will get async capabilities up and down the whole of Django.
Once we get to that final point, it may be worth considering using the async features of Django for stuff like web-sockets, but at the moment we can't even take advantage of the fact we can now deal with ASGI as well as WSGI servers. You can use Django with an ASGI server, but there would be no point as the base handler is still synchronous.
TLDR
Django channels adds a way to deal with protocols other than HTTP, and adds integrations into things such as django's session framework and authentication framework, so it's easy to add things like websockets to your django project. It is complete and you can start working with it today!!.
Native async support is a fundemental re-write of the core of Django. This is a work in progress. It's very exciting, but won't be ready to really benefit from for a little while yet.
There was a good talk given at last years djangoCon outlining the plans for async django. You can view it here.
Related
I just have two questions:
is there another way to add a real-time update for your django app rather than using Django channels? please if there is another way let me know because django channels requires a lot of changes on the server settings and it's just a pain on the ass to implement them.
I once used Pusher instead of django channels and websockets It just worked well on my app and i didn't have to install django channels and my app worked just fine on WSGI mode? I'm really confused how this was even possible if any one here is an expert on the subject can you please explain how Pusher works and why we need Django channels in the first place since as far as i can see implementing pusher with django is so much easier than using django channels.
Thanks in advance
I'm trying to find some "django-socketio" repo to use in my project. I using django 1.10 and python3. I really searched but I do not found working examples with python3.
My poor workaround
I started node project and put socket.io inside route
In my django view I send returning data to node route with my django session
I manage session coming from django inside my node and emit inside
route to client.
This work but I can't believe this is a good solution.. Anyone have other ideas? Or working examples with python3 and socketio?
Thanks!
If you want to use Websockets and Django you should consider https://github.com/django/channels. The alternative in Python would be using python tornado http://www.tornadoweb.org/en/stable/ or aiohttp (Python3.4+) http://aiohttp.readthedocs.io/en/stable/. Many of the implementations of Django with asynchronousity through gevent are outdated, experimental or abandoned, I found this https://github.com/jrief/django-websocket-redis but it uses Redis so no reason to not going back to django-channels.
In my opinion, as Socket.io is a layer over Websockets you will not find any project that supports fully the Socket.io spec as a ws server in Python as it is a native Node.js not officially ported to Python project, at least the latest one you are probably using, if you really need Socket.io features stick to Node.js and create a simple REST API in Django to load the backend data asynchronously from Nodejs (the REST django API will always be synchronous by nature), this is the best shot you would likely have.
https://github.com/django/channels/blob/master/docs/getting-started.rst
django-channels works with python3 and django >=1.8 :)
And you can change pip to pip3
I need to write a very light database (sqlite is fine) app that will initially be run locally on a clients windows PC but could, should it ever be necessary, be upgraded to work over the public interwebs without a complete rewrite.
My end user is not very technically inclined and I'd like to keep things as simple as posible. To that end I really want to avoid having to install a local webserver, however "easy" that may seem to you or I. Django specifically warns not to use it's inbuilt webserver in production so my two options seem to be...
a) Use django's built in server anyway while the app is running locally on windows and, if it ever needs to be upgraded to work over the net just stick it behind apache on a linux box somewhere in the cloud.
b) Use a framework that has a more robust built in web server from the start.
My understanding is that the only two disadvantages of django's built in server are a lack of security testing (moot if running only locally) and it's single threaded nature (not likely to be a big deal either for a low/zero concurrency single user app running locally). Am I way off base?
If so, then can I get some other "full stack" framework recommendations please - I strongly prefer python but I'm open to PHP and ruby based solutions too if there's no clear python winner. I'm probably going to have to support this app for a decade or more so I'd rather not use anything too new or esoteric unless it's from developers with some serious pedigree.
Thanks for your advice :)
Roger
I find Django's admin very easy to use for non-technical clients. In fact, that is the major consideration for my using Django as of late. Once set up properly, non-technical people can very easily update information, which can reflected on the front end immediately.
The client feels empowered.
Use Django. It's very simple for you to get started. Also, they have the best documentation. Follow the step by step app creating tutorial. Django supports all the databases that exist. Also, the built in server is very simple to use for the development and production server. I would highly recommend Django.
I am trying to run Jumo open source platform ( https://github.com/jumoconnect/openjumo) on my local machine (Windows 7). I have Python and Django installed and it works - I can create new project without problems, but I am not sure how to set existing project and make it work.
I am not experienced with Python/Django, so first I need to know whether it is hard task or not. I guess it's much complicated then installing WordPress or Joomla, but does that require a lot of work in order to set it up?
Can someone write some kind of guide if it is not too complicated? Or if there is some tutorial that explains how to do that, that would be great.
Just to be clear, I am not trying to learn something in one day, just want to see if this first step in using this platform is too hard, and if it's not, I'd continue learning, because this is exactly what I need for one project.
I use Python 2.7 and Django 1.3.1
Thanks
This project has a lot of external requirements which are not listed anywhere and unless you are comfortable and familiar with django, I wouldn't recommend installing it. Here are some but not all of the requirements that you'll need running:
Celery and django-celery
RabbitMQ (a broker for Celery), or another broker but then you'll have to edit settings.py again.
memcached (this is optional, as you can use django's own session middleware for development), but if you simply download the code and try to run it, you'll run into an error since the default settings.py has the default middleware commented out.
grappelli
django-jenkins (not required, but again, unless you edit the default settings.py, you'll get errors).
django-tastypie
django-debug-toolbar
Data science toolkit server
as you may know Django is a powerful web framework and Python is a programming language, for python itself you need more than a few months to become some kind of expert.
it's very easy to start, but not that easy to learn the whole stuff. Django is one of the most or maybe the most powerful web frameworks (beside Ruby on Rails).
my advice to you:
learn python's basics (there's many books such as dive into python,
...)
learn Django basics (Django Book)
use Django on a Gnu/Linux (for example Ubuntu)
learning basics of Django can be done in a few weeks.
consider deploying a Django website is not that easy. you need to know a little about Apache web server.
www.djangoproject.com
note that in python (like other programming languages) you need to define working path. errors mentioned in question's comments usually caused by this.
also you should check Python installation path. sometimes these kinds of errors occurs when there is a project with the same name as yours in python installation path.
I am about to start ramping up on Django and develop a web app that I want to deploy on Google App Engine. I learn that Google has Django 0.96 already installed on the APP engine, but the latest "official" version of Django I see is at 1.2.3 and its a bit of an effort to install it there.
I am curious which version of Django is most widely used.
So, can you please guide me on which Django version I should ramp on and deploy based on the following criterion
Stability and suitability for production release
Availability for applications (or plugins) and which version is most supported by the community
Thanks a lot!
Most people are currently using Django 1.2. You should not use or learn Django .96 - it's VERY old, and learning to use it won't prepare you for any non-app-engine Django work since things have changed significantly since then.
Django on App Engine is something of a pain, since you lose a lot of the ORM, which is a really nice reason to be working with Django. You also lose the ability to simply drop-in plugins and reusable apps that use any of the Django ORM. Anything with a models.py won't work.
Take a look at google-app-engine-django for help getting a more recent version running.
http://code.google.com/p/google-app-engine-django/
There is work to integrate the GAE storage engine into Django, and several projects have variously working implementations, but I wouldn't expect really good ORM support for a while yet - 1.3 (which is still several months from release) will include hooks that make it easier to write NoSQL backends, but Django probably won't ship with one.
While there are security releases for old versions of Django, you should really be developing using the latest stable version. Major releases of Django have a very strong backwards compatibility promise, so going from 1.2 to 1.3 when it comes out will be pretty seamless.
I strongly encourage you to think long and hard about what precisely App Engine offers your specific application before spending a lot of energy getting things working there. You lose application portability, scaling is still hard, and you don't save money if your application gets popular. App Engine is not a forgiving introductory platform.
For more conversation on this topic, take a look at this question:
Why use Django on Google App Engine?
particularly my answer there and the comments on it.
app engine permits you to use other versions of django out of the box, with only a little pain, using google.appengine.dist.use_library. essentially, your main.py (the module specified by app.yaml to handle urls) should look like this:
import wsgiref.handlers
from google.appengine.ext import webapp
from google.appengine.ext.webapp import util
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from google.appengine.dist import use_library # important bit
use_library('django', '1.1')
import django.core.handlers.wsgi
def main():
application = django.core.handlers.wsgi.WSGIHandler()
# Run the WSGI CGI handler with that application.
webapp.util.run_wsgi_app(application)
if __name__ == '__main__':
main()
Another thing to consider is how you install. I'd be sure to install django from SVN, because it makes updating it MUCH easier.
I have been using the dev version for a while on my site, and haven't encountered a single bug yet, aside from one that affected the admin site in a minor way (which a svn up fixed).
I don't have a feel for whether people are using 1.2 or dev, but in my experience, dev is perfectly suitable. Any major errors that you may have in the code will get fixed very quickly, and svn up will get you to the latest code on the off chance that you get a revision with a major bug.