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?
Related
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
I am setting up a server for my android chat app. It is a pure group chat i.e. each message will be sent to multiple users and not just a single user
Since I have a background in Python, I would prefer to pick a python based web framework.
So as I was searching, I came across "Django" and "DjangoREST". After reading a lot about them, it seems that DRF (Django Rest Framework) is a RESTful implementation of Django and will let you make applications that are light and scalable.
Since this is for the first time that I am setting up a web service, I can not relate or understand this completely. Also, I feel that what I want to accomplish, could be accomplished on either of the 2 platforms.
Therefore, it will be great if some one could share some very basic and key differences(if any) between the 2 frameworks. So that I can decide which on to pick up.
There are no differences. Django is a web framework and Django Rest Framework makes it easier to create REST services in Django itself.
It doesn't replace Django. It adds to it.
I have an Django application at my work, only available on the internal network.
Currently we import data using Excel, but this is a terrible error prone process and I want to replace it.
I would like to provide a rich web application in Javascript which exposes some, but not all of the data from the main Django application (lookup values for menus). This would run on a server visible to the outside world.
So what is a good approach for this?
Management are concerned about security of making the main Django app available to the outside world, and I would prefer an intermediate tier as well - I think it would be easier to write a small server side app than to go through the current code and make sure it is secure enough to the outside world (I learned Django buildiong this app, so some of the older code is not done according to best practices, but does work as it needs to). I would also like it to hold the new data until someone has checked it looks OK before importing to the main database. (I am the only developer, so there are time considerations).
So two options I can think of just now.
1: Have a small Django app on an external facing server. This can communicate with the main app to get the values required for lookups, and store the input before it gets imported. The tables will essentially mirror the main app and need updated when the main app tables change.
2: Have something similar, but rather than use a database, use the external facing server to contact the REST interface on the internal server. Something like using Django non-relational to get data from the REST interface of the main app. Put an import table in the main database server to store the dats for approval.
Are either of these good / bad approaches?
Any other suggestions?
Are there any good resources for learning about n-tier apps?
If I understand you correctly you want a small Group of trusted users to be able to access an internal database. There is already an Internal Django App accessing that database.
Management is concerned about making this app or an extension of it available to the general Internet.
I think ther concerns are very valid. If you have only a limited set of users accessing the import functionality, push authentication out of the Django Web Application into the HTTP Server / Balancer / Frontend.
For example set up an apache external webserver forcing all access to your Django App beeing encrypted (HTTPS) and authenticated. Users can be authenticated via HTTP-Auth using static files on the server. Password changes / user additions have to be done by an admin logging into the server.
Only after completing this login the Django App with it's own authentication can be accessed. I would opt vor a smale seperate import App instead of extending the main app. This small app could run with reduced permissions on the main database for an defense in depth aproach.
This setup provides you with a litte additional interfaces / points of failures, while maintaining a small attack surface against random Internet users. You can hire a security consultant th audit your apache config and be assured that you locked out the greater Internet and only have to worry about HTTP-Authenticated users.
I have benn running such setups for 15 years by now. Users are annoyed by the double authentication and password saving in Internet Cafes is an issue whith HTTP-Auth but generally it is verry seamless if once set up.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
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.