How to use django-ddp - django

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.

Related

Django, FastAPI and DRF

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.

Do I need to change my normal Django code when introducing Django Channels?

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.

Standalone REST API & Standalone React SPA vs Django and React combined

I would like to create a React SPA, which is fed by querying a Django REST API.
I was reading this, and I encounter this point:
I see the following patterns (which are common to almost every web framework):
React in its own “frontend” Django app: load a single HTML template and let React manage the frontend (difficulty: medium)
Django REST as a standalone API + React as a standalone SPA (difficulty: hard, it involves JWT for authentication)
Mix and match: mini React apps inside Django templates (difficulty: simple)
It seems that in case of an SPA (Single Page Application), it would be better to choose 1. As far as I understand, the React app would just be a big file with all the required css, html and js, right?
So we just create this file, and serve it on a specific endpoint of the Django app. Then, I do not understand the benefits of the "standalone" way of doing things. We would need two different domains, it would cause issues with authentication, and the standalone SPA would in fact just be serving a static file right? Is there a reason why it would be interesting to use a standalone SPA?
But when I read React in Django or React as a standalone?, it is advised to keep front-end and back-end separated. I wonder what I am missing, and what is the benefit of creating a standalone React SPA. reactjs - React in Django or React as a standalone? - Stack Overflow mentions that it would allow backend to be reused by different applications, but I do not understand what would prevent my backend from being reused if it is serving a static file. My backend will not disappear, it will still be here, ready to be reused, right?
pt1. yes the react app is bundled into a couple of files that you can use in your html template
pt2. standalone would be interesting if you already have a large Django project running, and you cannot afford migrating everything to a React SPA
pt3. You are correct in stating the backend is just another application serving content, and can be accessed like any other API. The difference lies in the content being served: When creating a React SPA, the backend is only concerned about what data is requested and what data needs to be persisted to the database. Now your frontend code can focus on specific frontend problems, such as user experience and browsing/navigation of the user: For example utilizing the Redux store, where you can store your JWT token in the browser session, or cache already retrieved data that might be useful on other pages. This offloads the backend considerably because you don't need to send the same data twice.

django channels vs daphene

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.

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?