I am little bit confused about the main roles of django-channels and uvicorn server. I have read a lot of blogs but did not get much clarification.
If we can implement an ASGI server for websockets using channels, then why do we need asgi server seperately like daphene or uvicorn?
Daphne is a ASGI server while Django Channels is an ASGI Framework for Django.
Links have been taken from www.uvicorn.org.
Also reference from another blog is mentioned below:
Channels was created to support asynchronous protocols like Websockets and long polling HTTP. Django applications still run synchronously. Channels is an official Django project but not part of core Django.
Django Async project will support writing Django applications with asynchronous code in addition to synchronous code. Async is a part of Django core.
Both were led by Andrew Goodwin.
These are independent projects in most cases. You can have a project that uses either or both. For example if you need to support a chat application over web sockets, then you can use Channels without using Django’s ASGI interface. On the other hand if you want to make an async function in a Django view, then you will have to wait for Django’s Async support for views.
Related
I want to make a project, which uses Django as backend, PostgreSQL as database and FastAPI with Django REST Framework for REST.
Don't see any problems with making a project just with Django, DRF and Postgres, but face with difficulties when speak about FastAPI and DRF at the same time.
So there is no problem in connecting Postgres to Django, and there is no problem to make endpoints for DRF.
But how can I connect fastapi? Where to place endpoints and how to run all this stuff together?
In some examples I saw that FastAPI isntance is initiated in WSGI.py and then server runs from calling commands such like this:
uvicorn goatfish.wsgi:app
But i am not sure that it works like this when I mix more than only Django and FastAPI.
I want to use FastAPI for optical character recongnition and DRF for user registration, logins etc.
Are there any advices about making project with such a structure? Or maybe someone have a repository with such kind of project on github?
EDIT: Hope to see answers here, but for now I only see the solution in making classic Django + DRF app, then make FastAPI app with endpoints, run these apps on different ports and do some chain of actions:
From django app we load an image to form and when we submit this form we send POST request to FastAPI endpoint, which will run OCR process and then return JSON with recognized text and then will send this JSON to the Django Callback endpoint, which will process it and save to the database.
What do you think about such thing?
I think, you may:
Mix of fastapi+django. But this is only for replace DRF and use fastapi as rest framework.
Microservices. You may to run Django on one port, fastapi - another. And both may to use one shared database.
Mircoservices. All from point 2, but some api tasks (for example sign-in/sign-up) on Django and another - on fastapi.
As an alterantive you could use django ninja.
It uses similar concepts as FastAPI (Routes, Pydandantic Model Validation, Async Support) but is an Django app.
Which of course is more the monolithic approach but still valid.
Well, so after few days of thinking about I decided, that there is no sense in a question which I asked :)
Here we should talk about microservice architecture, where such kind of problem just doesn't exist. All we need is to make as much services as we need in our project using any framework (Django, FastAPI, Flask, Ruby etc.) and make connections between them.
As example I can run my main Django server on port 8000, my FastAPI server on port 5000 and my DRF service on port 6000. And then I can just do whatever I want from my main Django server making requests to endpoints of FastAPI and DRF.
So that's very simple example, now I'm diving deeper into microservice architecturing, but that's definitely what I need.
Hello I am a beginner in the python world, so I am still trying to understand the care when working with ASGI. I read some tutorials and documentation, as well as watched some videos on youtube. However, I was unsure on some points.
I have a small backend application using Django + Django Rest Framework.
My code is very trivial, composed of the most common concepts in the framework: views, serializers, models, urls, etc. In addition, I use a relational database.
My environment is this:
Python 3.8
Django 3
Django Rest Framework 3.11
Now, I need to add support for WebSockets and I did the basic configuration described in the Django Channels tutorial:
I installed Django Channels 2.4.0 (Daphene 2.5.0)
Added 'channels' to INSTALLED_APPS
I created a routing.py file with an empty ProtocolTypeRouter
I added ASGI_APPLICATION to my settings.py
I configured the asgi.py file to use channels
At the moment, I have not configured any channel layers
At the moment, I haven't created any WebSocket endpoint
After these configurations the runserver is using an ASGI development server and apparently my REST endpoints are all working.
Some questions:
Considering that all my code is synchronous, wouldn't it be necessary to make any adjustments to it?
This configuration above, already does all the magic necessary for my synchronous code to be executed safely in daphene considering that it is an ASGI server?
Can I serve normal HTTP and WebSockets requests using only ASGI in a reliable and stable manner? Or, is it recommended to serve HTTP traffic using WSGI and leave only WebSockets traffic to daphene?
Where exactly should care be taken regarding synchronous code?
These are my answers based on previous experiences with Django Channels 2 ...
1) Considering that all my code is synchronous, wouldn't it be necessary to make any adjustments to it?
You can safely keep your existing sync code: no adjustments are required; just make sure to call the “sync version” of django-channels API (i.e. SyncConsumer instead of AsyncConsumer).
On the other hand, Channel Layers uses a different approach, and provides only an async version.
When the call is issued from sync code, you need to use the async_to_sync wrapper; for example:
from asgiref.sync import async_to_sync
async_to_sync(channel_layer.group_send)(
group, {
"type": 'data_received',
"content": data,
})
2) This configuration above, already does all the magic necessary for my synchronous code to be executed safely in daphene considering that it is an ASGI server?
The single missing details is (in settings file):
ROOT_URLCONF = 'project.urls'
3) Can I serve normal HTTP and WebSockets requests using only ASGI in a reliable and stable manner? Or, is it recommended to serve HTTP traffic using WSGI and leave only WebSockets traffic to daphene?
With Channels 2, you can safely choose to use Daphne for both HTTP and WebSockets requests, since Daphne will auto-negotiates between HTTP and WebSocket; this is what I usually do in my projects.
Splitting HTTP and WebSocket traffic, thus:
running standard HTTP requests through a WSGI server
using Daphne (or uvicorn) only for things WSGI cannot do, like WebSockets, HTTP long-polling or other IoT protocols
is possible, but entirely optional.
I'm using django as backend. While reading stuff about meteor, i found django-ddp.
I searched a lot, but I didn't get what django-ddp is for.
I understood that you can use it to connect meteor to your django backend, but what is the use case?
How does the client connect to django and/or meteor? Does meteor have to run on the same server? How are the http requests handled?
Maybe a tiny example would help me to get this.
For me important: Can i use this to combine benefits of django and meteor?
Django DDP provides a Meteor compatible, realtime, latency compensated backend framework for Django (Python) models. It can also serve your Meteor frontend code (HTML/JS/CSS/...) allowing you to avoid using Meteor (and node.js) on the server, whilst serving regular Django views at the same time.
Django is a respected web framework with a powerful object relational mapper (ORM), with support for schema migrations included by default. Django DDP is efficient and secure, using gevent to handle HTTP requests and manage concurrency at the process level, and multiple processes (across multiple hosts) to allow scaling-out to serve many clients simultaneously. WebSockets are handled using gevent-websocket. Combining these aspects with the realtime, latency compensated benefits of Meteor does indeed give you the advantages of both (unless you prefer to run node.js on your backend servers).
If Django DDP is used to serve your Meteor app then the client (browser) will connect to Django DDP automatically. Otherwise, you can connect your Meteor app to Django DDP and use the Django DDP connection like this:
if(Meteor.isClient) {
Django = DDP.connect('http://ddp.example.com/');
Tasks = new Mongo.Collection('myapp.Tasks', {connection: Django});
Django.subscribe('Tasks', {
onReady: function(error, result) {
// Log each matching Task to the browser console in a table
console.table(Tasks.find().fetch());
}
});
}
If you're serving your Meteor app from Django DDP then drop the DDP.connect line and omit the second parameter to new Mongo.Collection.
You might find the Todos example app a useful place to start. It includes a full working example of how to write both the Meteor client app and the Django DDP server app.
Disclaimer: I'm the author of Django DDP - sorry if parts of my answer sound like marketing guff but I'm just trying to answer the first part of the question.
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.
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.