Django real-time game backend - django

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.

Related

Django WebRTC TURN/STUN/ICE Server

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.

Django REST and React implementation model

I am currently creating a website hosted by Django. I plan to use React as my frontend framework. I have done some research on putting them together but most say that I should go for the SPA model and have separate web servers for frontend and backend. The problem is that I wish to use apache as a prod server with django and avoid having 2 separate servers. I have read about the hybrid model and having django serve static files with react.
My Biggest concern is security as I have already setup apache for security and I aware that node.js is somewhat insecure.
What would the best approach be. The separate SPA model or the hybrid model.
I'd say it's okay to go for hybrid model if the project is small and you are the only one working on it and you only want to make things done. I think it's kinda messy to create apps like this unless they don't really worth the time.
But if it's a big project and more than one developer is working on it or will work on it then i highly recommend going with separate web servers one serving frontend app and one django app.
Also note that you don't really need 2 different servers. You can use one server for both and use 2 different which is still not necessary and you can use one web server to serve both.
And security not something that different models can cause to downgrade or upgrade. It's up to you to configure the server and write both frontend and backend apps secure enough to do the work for you.
There are more than one web servers that are as secure as they can be and they work with both django and react pretty well. I used nginx many times to host both django and react apps and i had no problem causing by nginx itself whatsoever.
And for last piece of advice if you will; Creating good quality apps requires a lot of time and energy, working with different technologies that do really good for what they are made for and if you are planning to be a really good developer you should come out of your comfort zone and adapt with new technologies that comes out and they are coming out pretty rapidly which requires you to learn constantly and do things in way you are not used to yet and making things work even if they doesn't seem to be good together at the first look.

Is it reliable to build desktop applications using web frameworks like Django?

Is it reliable to build desktop applications using web frameworks like Django?
The idea is to
build the interface with HTML, CSS, and JavaScript
use Python and Django for backend operations (calculations, storage and databases, etc)
and then run a server locally so that
the interaction with the application is done through the browser
other local devices can access the application by connecting to the device on which the server is running.
If that is possible and yields a reliable experience, then
is the development server that comes with Django enough? If no, what servers are most suitable for our purpose? Is Nginx good for example?
what database should be used? PostgreSQL, MySQL, etc? The app will need to store a large number of entries.
I've never done this, but I can't see why not. You can use the Django REST Framework to create an API that your desktop application can talk to, in exactly the same way as you might with a JavaScript single page app.
But no, you should not use the dev server for production, even in a limited scenario like this. Apache/mod_wsgi or nginx/gunicorn are simple to set up and deploy.
For the database, it makes no difference. The Django core devs prefer postgres, but you should use whatever you are comfortable with.
You are asking for a webApp, so yes you can. Is not use the Django server, instead is very common use nginx for Django, and the best database is postgres for Django.
If you want to pass your project like a desktop app is better use Django server and SQLite for avoid create a new database server.
Database
I find this answer explaining why is postgres better for Django

Running a meteor app as part of a wider django project

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?

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