When Django App A completes an action I want it to add some data to Django App B. They are currently on different domains but the same server.
Option 1.
I've tried doing POST requests both with jQuery and using python-requests but in both instances the POST is converted to a GET. Suspect this a cross-domain issue and have applied the cross-domain middleware and the various changes to the headers suggested but still not cracked it.
Is this the best approach to pursue?
Option 2
I could set up a shared database so A writes to it and B reviews it and picks up the data. This seems very clunky.
Option 3
Some sort of messaging/queueing system. Redis? Celery? From a read of the documentation it is not immediately obvious to me how I implement the setup I need.
Option X
Another approach?
Option 1: Try a webservice API framework for Django like TastyPie. JSON was designed for data interchange, it allows completely different systems to talk.
Option 2: Don't duplicate data. There is nothing wrong with both apps accessing the same database, infact this makes perfect sense.
Option 3 Option 3 makes little sense for what you are trying to do.
Related
So I just created a website's front-end using ReactJS. Now all I need is a backend database that I will fetch data from using requests.
The question is whether I need to render templates using my backend or just use my server to make requests (eg get, post etc)
PS. I will be using Django as my backend.
Thank you everyone who will help me out.
Doing both is recommended. Based on the requirements and use cases we must use both ways to render.
For example, Some products use initial html as a Server side rendered page with all essential data required inserted as scripts and so on. This helps in loading primary content faster. If we are not following this in applications that require data initially. Then it might take more time to fetch React chunks, scripting and after seeing an API makes request, and then getting data and then displaying the primary content. So when a page needs more data (like More API calls) then server side rendering might be a good way.
For other scenarios like getting user details, All these can be done using React.
No, because you will use DRF (Django Rest Framework) to communicate between frontend and backend. Basically you will write your own APIs in the views.py that will respond with JSON data, at least in major of cases this will be enough. So, you don't need templates, since template are really Djangos' frontend, that you will not be using at all.
But, this heavily depends on what you are doing and what is your setup.
I have an existing Django project in the sports domain with apps that are built on the Model-View-Template structure. Many of the models and views are fairly sophisticated and work well currently. Data from the database (scores etc) is combined with some incoming user inputs through forms (HTTP POST requests) to be displayed on a web page via templates.
However, I now need live data to be displayed to users and be automatically refreshed to all the users continuously, either because one of the users entered something new (in the front-end), or because the scores changed during the game (directly enters the back-end).
I've done some research on Stack Overflow as well as tutorials on Youtube/ rest of the web and it appears that for me to use Django Channels, I'd have to start from scratch and build everything ground-up, which I'd like to avoid. How do I use the websocket protocol for my Django app easily without having to completely rework everything that I've done so far?
You don't really need to start from scratch or anything. You just need to add a module using channels. I am assuming that currently, the data is fetched only when the page is refreshed. What you need to do is write a consumer that is used to send messages directly to the client via websocket. Then in the front you can update the widget with the scores on each message received in the websocket. You can also stream user actions through the websocket to the server which will then be broadcasted by the consumer to needed clients. You may not even need to change anything in the existing code.
It will be easier to understand how this works and how you can incorporate it to your project by reading the channels tutorials. It became clearer to me after reading it so I would advice you do the same
My UI designer is making me a rich html and java script front-end which is supposed to work with my Django server. I have provided him a bunch of APIs to get different elements from the server. (i.e. an api to load the images, another api to load some text, another api to load bigger size image when somebody clicked on a small one, etc.) The problem with this is that every time a user visits the page, I will be getting some number of requests.
On the other hand, I could have used django template tagging to render the page once with all the elements needed. however,
I was wondering if there is a clear benefit in one of these options?
As #limelights said, try not to optimise too early. Because you don't really know what will be your bottleneck.
And when you'll have problems, the first thing to check is your queries to the database. Do you use selectect_related() and are your indexes optimal for your requests. This include the queries that javascript make via django (Try to load all the child node needed in one or two requests, as select_related() do).
After that the next optimisation should probably be cache. Here's the doc about the django's cache framwork.
After that there's adanced optimisation with database denormalization, apache or nginx optimisation, mysql or postgresql settings optimisation, load balancing and etc... Those optimizationg should be done because you have a problem of popularity, not just for a few users.
I have 50 different websites that use the same layout and code base, but mostly non-overlapping data (regional support sites, not link farm). Is there a way to have a single installation of the code and run all 50 at the same time?
When I have a bug to fix (or deploy new feature), I want to deploy ONE time + 1 restart and be done with it.
Also:
Code needs to know what domain the request is coming to so the appropriate data is displayed.
The Sites framework comes to mind.
Apart from that we have Django running for multiple sites by symlinking Django to various docroots. Works like a charm, too.
I can see two quite distinct ways to do this:
Use one database and the sites framework. Every post/picture/whatever model is connected to a Site and you always filter on Site. This requires a separate settings file for every database.
Use one database for each and every site. This allows different users for every site, but requires duplication of everything that is stored in the database. It also requires a separate settings file pointing to the correct database.
Either way, you do not duplicate any code, only data.
--
If you need to do site-specific, or post-specific changes to ie. a template, you should read up on how Django loads templates. It allows you to specify a list, ie ["story_%d.html", "story_site_%d.html", "story.html"] and django will look for the templates in that order.
I just ran into this and ended up using a custom middleware class that:
Fetch the HTTP_HOST
Clean the HTTP_HOST (remove www, ports, etc.)
Look up domain in a Website table that's tied to each account.
Set the account instance on the HTTPRequest object.
The throughout my view code I do lookups based on the account stored in the HTTPRequest objects.
Hope that helps someone in the future.
Im still fairly new to Django, so please explain things with that in
mind.
I'm trying to create three websites using 2 subdomains and 1 domain:
for the blog, blog.mysite.com
for the forums, forums.mysite.com
for the custom web app, mysite.com
When building the custom web app, I used contrib.auth to make use of
the built-in django provided user models and functionality.
For the forums, I am planning on using SNAPboard (http://
code.google.com/p/snapboard/) with minimal, if any, modifications. On
initial inspection, it looks like it also uses contrib.auth users.
For the blog, I will probably be rolling my own lightweight blogging
app (since that seems to be the Django way and, also, b/c as Bennet
mentions, there is no killer Django Blog app)
Currently, I am considering two features that require some integration
between the three sites. First, I want to have the users of the custom
web app to use the same account to also log into the forums. Second, I
also (but I haven't figured out how I'm going to do this yet) would
like my blog posts to automatically become a topic for discussion in
the forums (this is just an idea I had, I might end up dropping it).
Ok, so to my questions:
1) Again, I'm new to Django, but this integration leads me to believe
the three websites need to be all under one project. Is this correct?
2) How would I accomplish the url structure for the websites that I
described above (blog.mysite.com, etc)? In the project's urls.py, I
don't know how to filter off of subdomains. If it was mysite.com/
forums/, that would be easy, but I don't know how to to catch
forums.mysite.com and forward it to the appropriate Django app.
3) Would I have to make use of the django.contrib.sites framework? I
don't understand that framework fully, but it seems like it's used
when two different websites are using the same django app in the
background. Whereas my three websites are all using different django
apps, but I want them to share a little bit of data.
Thanks for your help.
1) Yes, it's only true way for that
2) Use middleware
3) No, you don't need it.