What library to use for comet in Django? - django

I'm planning to write a comet application in Django, but as far as I can see articles on this topic are scarce, and the comet libraries that are available don't necessarily lend themselves to use with Django (especially the development environment).
So far the best options I've seen (with one article on how to get it started in Django each) are APE and Orbited. Orbited, however, doesn't seem to still be actively developed (easy_install doesn't even work, the domains have expired), and APE should work fine, but how does one get it to work with python manage.py runserver ?
So my question is - if you are writing a comet application in Django, what library is most commonly used, if any?

My solution for this would be to write all of the models and main site in Django, but use another server for the ajax which is more suited to long polling or persistent sockets.
For example: SocketTornad.IO
https://github.com/SocketTornadIO/SocketTornad.IO
Inside the tornado socket.io server, the idea was to import the required Django models to work with the data required by the comet / websocket views.
Doing that through manage.py or any plain django server seems very difficult, and it would much easier to let the tornado socket.io server do the specialized comet/websocket work for you.
But, I have not actually implemented it yet, since basic non comet ajax has met our needs fine. It is just a concept that was considered.

Related

communication method between django <-> application server (node.js)?

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.

Live notification/chat in django

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.

Django real-time game backend

I plan to make an online game. It will be a full real-time during play. For my website backend I have used Django. Database and other things are almost done. What is the best way to make user client side and server side backend for play in realtime? As I use Django it would be nice to have it in Python.
We plan that there will be minimum ~1000 online players all the time.
Twisted/Tornado/Node.js or maybe something else?
Thanks in advance.
Tornado is very light and pretty nice in my opinion. You could integrate it with Django in various ways -- e.g. Integrate Tornado in Django, Integrating Django with Tornado's web server -- or just run it alongside Django behind whatever web server you use.
Node is so fun that you might tire of Django. :-)
I think you should keep separately Django - which is used for general site functions, and Tornado - which is used for realtime data. I think you should use some Redis to store/read data and communicate between django and tornado, so prevent using database access directly from tornado.
Developing your own backend server sounds as interesting project.
But from my experience it becomes a very significant of your R&D effort.
It starts with developing core backend components, dealing with servers, installs, patches, security issues and more.
On top of it, you will need to create admin systems to manage your player, levels, xp, integration to stores and more... and then, you have the reports (installs, retention, etc'...)
I would strongly recommend using existing backend platforms.

Is Tornado a replacement to Django or are they complementary to each other?

I have several questions about Tornado and other web frameworks.
1) Tornado claims to be a webserver (a non-blocking one, therefore much performant), so some people said it does not play the role of django --i.e., they say tornado is not a web framework.
However, it does provide a web framework I think (http://www.tornadoweb.org/documentation#main-modules) -- in this way, it seems to replace django as the web development framework.
Is my above understanding correct?
2) Normally, several Tornados are set up behind Nginx. Tomcat is also normally set up behind Apache web server. Can I say Tornado plays exactly same role of Tomcat does for Java web server? If the answer is yes, then Tornado IS a web framework.
3) I read some article saying using Tornado and Django together, such as http://www.jeremybowers.com/blog/post/3/on-deploying-tornado-web-server-framework/, but I read some article online claiming that "if you use Django, then you lose the asynchronous from Tornado", is this true or false?
A related question though, if Tornado is itself a web framework as I said in 1), why people bother using Django at all? (to result the plugin?)
Can someone give me a 101 introduction?
To answer the question,
NO, Tornado is not a replacement to Django. It's an alternative.
YES, they are complementary to each other but not in the same process (*)
I would use Django when it's a big team effort and/or needs to run on a SQL database.
I would use Tornado for everything else. Ie. personal projects, WebSocket-related apps, or apps that use a NoSQL backend.
(*) Don't bother running Django inside Tornado or the other way around unless you really have a strong requirement for that.
Tornado is a web server and a web framework by most definitions, but it's quite a minimal framework (compared to Rails or Django). Tornado modules are loosely coupled, so it's possible to use just the web server component (or even just the lower level IO loop). Compared to Django, there are a lot of areas where Tornado doesn't have as much functionality. For example, there isn't really a model abstraction in Tornado, you have to roll your own.
When you run a Tornado app behind Nginx, that's your app running – Nginx just proxies to it. I believe Tomcat is an application server, distinct from your application. I wouldn't call Tomcat a web framework.
[Update: Django added support for async views in 3.0 and some ORM queries in 4.0. This point is no longer accurate] Django is not asynchronous, so generally your app will block while using the Django components. This may not be a big deal, it depends what you're doing. The Tornado devs have stated (paraphrasing heavily) that for most applications, the biggest win comes from not blocking while waiting for the client, i.e. web browser. Blocking on the database, for example, is not a big deal if you keep your queries fast.
There are a lot of pros and cons for both Django and Tornado, and there are many alternatives to both - it's definitely not just a choice between the two. Here's a very quick list of why you might want to use Django though:
Pros for Django:
it's a fuller stack (admin pages for example are very easy to implement)
it's much more established (plugins, tutorials, etc.)
it's better documented
its ORM is very nice

Django: Moving from XAMPP to Django questions

I've worked with XAMPP, WAMPP, MAMPP, etc and am starting to look at Django.
A majority of the work we do is very CMS orientated; although we've been told not to use third-party CMS' (mainly because of user's find them hard to use, and other issues), I've found that I can code a very simple CMS using Cake, CodeIgniter or one of the other PHP frameworks.
And yet, I'm getting increasingly frustrated with the amount of coding I need to do just to get something up and running, and I've been told that Django is a good Python framework to use. It also seems to get a lot of buzz from reddit.
I have some concerns and queries about moving from XAMPP to Django.
1) Security
Any web app should be coded defensively. Over the past few years we've seen a movement towards protecting against XSS, SQL injections, Cross site forgeries, session fixation, session hi-jacking, cookie hi-jacking; the amount of security one needs can be overwhelming.
What things does Django do to prevent/limit XSS, SQL injections, Javascript injections, and santizing input; one normally associates with securing PHP web apps? Is it something I need to worry about, or does Django do all this stuff out of the box.
2) What goes in the /www/ public folder?
In a manual I read it said not to put manage.py or the other .py stuff in the main webroot, so this means I put everything outside of the webroot; so what goes in there?
Do I put the /templates/ directory inside the webroot? How does the server know what to run?
3) Can I still use .htaccess on Django projects? I am familiar with Apache and often use it to do routing, or blocking off bad bots, but will using .htaccess still work?
4) Cronjobs
Do cronjobs still work with Python/Django projects?
5) Running Third party perl/other scripts
In PHP you can use other libraries such as the curl library, ffmpeg, ImageMagik as well as many others; can I still use these libraries with Python/Django?
6) Admin screen
Django gives you an out-of-the-box admin screen; is this only for development purposes or can it put live? I am concerned about any the security of the admin screen.
7) Integration with Discuss, Facebook, Twitter, OpenID, captcha, etc.
There are libraries in PHP that help integrate DisQuss, Facebook, Twitter; but is it relatively easy to do an integration with these and other third party apps?
8) E-commerce, SSL
Are there many e-commerce sites that use Django? I've seen a lot of CMS/Blog type software but not many e-commerce sites. By which I mean, shopping card, Protx/Paypal or Worldpay integration.
That's another thing; there are sandboxes for Protx, Paypal, Worldpay etc for PHP -- but are there any for Django?
9) Is it worth it?
Is it worth moving to Django from an XAMPP background? Will it really make things faster, or is that just marketing hype?
Thanks.
Security. The Django core team are very security-conscious, and have taken great care to make things like SQL injection impossible. The next version, 1.2, includes a whole new cross-site request forgery protection library. Obviously, you still need to be aware of these when developing your application, but Django does a lot to help you.
What goes under /www/public: Nothing. Django doesn't work via the normal Apache serving mechanism: it hooks into (preferably) mod_wsgi, which needs a single file which then tells it to run the rest of the code. The templates can go anywhere, and are pointed to by your Django settings file, but again aren't served directly by Apache.
.htaccess: You don't really need it, because of point 2: you're not serving things in a filesystem hierarchy. The best way to do it is to set up vhosts and manage things that way.
Cron jobs: Absolutely. Django is just Python, and you can easily run Python scripts via cron. Django allows you to set up custom command scripts which initialise the ORM and give you access to anything you would need.
Libraries: Again, because Django is Python, you get access to the huge amount of Python libraries that are out there. For curl, Python has urllib; for ImageMagick, it has PIL; and no doubt there are equivalents of ffmpeg too.
Admin: Again, security has been thought of from the beginning. Opinions differ as to whether you should use the admin only for your expert users, or customise it and allow access for all users; I've had a lot of success using it as the basis for my custom CMS interfaces.
Facebook, etc: Yes, there are libraries for all of these.
E-commerce: There is a whole e-commerce project, Satchmo, written in Django. Libraries exist to interface with all the payment providers.
Is it worth it? Only you can tell. My experience working alongside a range of developers who have moved from PHP is that they've enjoyed the experience and became much more productive.
On SQL Injections: Django uses an ORM, which takes care of SQL injection protection, and you will rarely write you own SQL. If you do, just follow the instructions on how to pass parameters to raw queries and prevent SQL Injections.
There is an entire chapter on the django book about security that should answer all your questions.
On what goes into /www/: anything that is not code? The concern is to not put the python code there.
On .htaccess: Yes, it should still work (for any non Django resources as Daniel points out).
On cronjobs: what do you mean?
On Libraries: Python - the language you will use with Django - is rich in libraries that probably provide the same functionality you are used to. This is a key point: you will need to learn Python well to benefit the most from Django.
On the admin interface: This is actually the thing that will probably help you the most, judging from your question. They are customizable (within some limits) and they really give the staff (it is not intended for public users, but for staff users) the basics of CRUD for your database models. It is a time saver. You might need to write your own templates for advanced functionality, but for most simple CRUD aimed at staff (which is usually the point of a CMS) it is very useful and easy to set up.
On integration: Check Pinax for a group of applications that provide extra functionality. There is a rich and diverse universe of integration solutions out there. It is not unusual to find questions here in SO about django + facebook and others.
On E-commerce: Check Satchmo out.
Is it worth it: Now, I have no experience with XAMPP. I know that I like Python better than both Perl and PHP (and Java, for that matter). I know that as a framework Django is simpler to use, faster to deploy than anything I used before.
My suggestion is the age old: go build a simple project and make up your own mind. You are the only one in position to decide if Django is the framework for you.
An older question on SO discusses some Django limitations. My answer to that might be helpful to you too.
I recently moved to developing any new projects in Django, coming from a PHP background. Here are my thoughts on your questions.
1) Security
Strings sent to templates is escaped by default, which takes care of most of that. Since you're using an ORM, SQL injection shouldn't be an issue unless you build raw queries for some reason.
2) What goes in the /www/ public folder?
Django doesn't use a file hierarchy for URLs like a typical PHP setup. The server knows what to run from your urls.py and settings.py pointer to the template folder.
3) Can I still use .htaccess on Django projects? I am familiar with Apache and often use it to do routing, or blocking off bad bots, but will using .htaccess still work?
As noted above, it works for static content just the same. For dynamic pages, you'd want to implement some other form of authentication or redirection for clients you want to block, as far as I know.
4) Cronjobs
There's no reason why you can't use cron for whatever, as you still have a normal Linux system.
5) Running Third party perl/other scripts
You'll want to use the Python versions of those libraries, of course. For instance
FFMpeg
PythonMagick
I replaced most of my need for Curl with the built-in urllib and urrlib2 libraries, but there is also PyCurl if you need it.
6) Admin screen
The Admin screen is intended to be used by your own admins, i.e. site staff. It may be possible to do so, but it's not supposed to be the scaffolding on which you build your public facing project.
7) Integration with Discuss, Facebook, Twitter, OpenID, captcha, etc.
There are a lot of people out there using Python and Django, and I haven't had any problem finding libraries. In my experience there is a bit less support for something than PHP, but what is there is often higher quality.
8) E-commerce, SSL
I haven't tried payment integration, so I can't say. Not sure about the other sites, but the Paypal Sandbox is run by Paypal, isn't it? I don't think it's related to what you're using on the server, so sure, you can access it like normal.
9) Is it worth it? Is it worth moving to Django from an XAMPP background? Will it really make things faster, or is that just marketing hype?
I moved to Django because Python is truly a more compelling language than PHP. Will it make things faster? I'm not sure what the advantages in that respect would be for Django vs.the PHP MVC frameworks. There are no magic bullets.
You do have to keep in mind that you're not just learning a new framework, but also a new language. There will be a bit of a learning curve if you've never used Python before. but I've found both Python and Django to be fairly easy to learn. The clean design of the language is fantastic and Django is veryt well designed, too. I do feel that it's boosting my productivity. I've found snippets for or articles about most everything I need to do in Django as I've been learning, so adapting has been pretty simple.