For reasons out of my control, 2 Django projects were placed on 2 different AWS servers, both using the same RDS AWS database.
I want Project B to be able to access and manipulate the models (tables) used in Project A (where they were originally created).
Is this at all possible? Importing the Project A app over the network via the PYTHONPATH in some way?
Sorry...I lack the reputation to comment otherwise I would not have posted.
I think in this situation, you may need to make use of the Django REST Framework.
This way you can simple authorize the projects to talk to each other, DRF comes with httpbasic built in, but you probably should try to set up some type of hashed token as part of the auth.
I found this guide recently...although it's specific to mobile devices, it's probably one of the better walkthroughs of the DRF.
Related
My team and I are having a hard time defining the architecture for my backend environment using Django.
To contextualize a little, we built an application similar to an App Store, for all our developments to be displayed, with the difference that it also launches the apps.
To maintain all the information about this apps, we built this backend in Django that is basically a database accessed through an API from the App Store, and a Django Admin website to register the informations to be delivered in the API (the one Django automatically generates).
The thing is, today, we have only one technology involved and therefore only one database and one Django Admin. But, other areas in our company want to use this architecture we built, with other apps and therefore other informations, not related to our environment.
The question is, should we deploy several Djangos in different ports of our server? Or should we try to create a dependency in our models to a "Technology" related to it? (For this option it is important to note that our architecture is complex and highly nested). Or maybe should we use the multiple databases provided from Django?
Has anyone had a situation similar to this one?
Thank you in advance!
The problem for me with creating a dependency in our models to a "Technology" is has to do with what OP means with other informations which are not related to OP's environment. Is OP able to create a database model that works, whose system is not overly complex and that can accommodate for all of the cases OP wants? If that's the case, I don't see why not.
There's an interesting Q&A talking about having multiple instances of Django in the same server. Personally I have already deployed in virtual shared hosts whose logic was essentially that, with the limitation that OP is sharing with other people too. OP can see in that thread that there are various cases where it was a viable option. Personally I find such shared hosts only viable in initial stages as they weren't as performant... but a great way to save resources if one is working with tight budgets. IMO this can be one of the best options for OP's case... which is considered single-tenant.
In regards to multiple databases, this automatically leads me to an approach to multi-tenant applications (within the multi-tenant applications there are approaches where one only needs one database as well). OP wants to go for this case if OP's application can serve all of the users from the same host, which doesn't seem the case for OP, unless OP is able to create a dependency in OP's models to a "Technology" (as addressed in the first paragraph).
I've researched on how to handle multiple websites with Django but nothing seemed really convincing to me: here, here and here
Here is what I have now:
A single Django project running on a server, with two apps. One for the API (with django REST Framework) and an other app which basically consumes the API and display the datas (retrieved directly in the database). My database is Oracle and on a separate server for robustness reasons.
Here is what I would like to have:
Two websites, one would be the API (certain users use only the API) and the other one would be the website (for the other users).
I obviously need those two websites to share the same database (but this shouldn't be to hard to handle in the settings.py file), and I also need to use the same Models, Admin, etc...
How can I handle that with being as DRY as possible ? If I make two django project, I'll have to duplicate my models, my admin, and certain business classes and functions... Which could be a pain to maintain.
The alternative would be to play around with virtualhosts and url redirections to make it seamless.
What do you think is the best solution ? And can you provide an example of implementation ?
Thanks!
There are few options:
Create 2 projects and a django application. You create the django application for the common code, like the models. Then you create 2 projects and use that application in both of them.
Create 1 project with 3 applications 1 application for common code, 1 for API and 1 for app. The API and app application will use the common code application.
Create just 1 project with 1 application. You'll have to create different views for the API and for the app and map a different url for each one.
The options are sorted by overhead while the first option has the most overhead, but it's the most organized solution.
Which is best? it depends on the size of your project. The bigger - the more the overhead will pay off. If you don't know what is going to be the size of the project in the future, then I would start with the third option, and as the project grows, move towards the second and first options.
I wrote a django project that is some kind of a CMS.
Now, I want to be able to create several accounts that use that CMS, Each with a different database.
For example, user can create himself an account in my service - and he will get a site based of that CMS.
How can I get started doing this?
Look at the django docs https://docs.djangoproject.com/en/dev/topics/db/multi-db/ There are is useful example. Another good article https://thenewcircle.com/s/post/1242/django_multiple_database_support
Unfortunately Django is not suited to dynamically switch databases at runtime. You either have to implement really hackish solutions (like mentioned in this question Django multiple and dynamic databases ) or to go with several independent Django instances which you will have to start up on your server dynamically.
A much simpler solution would be to stick to one database and distinguish different users' content by some other means, like Django Sites framework. The only problem with this approach in my opinion is that you will have to carefully set up your admin site configuration, so that users don't see each other's objects (in case you planned to use built-in Django admin).
I have a Django web front-end that consumes data from a REST API backend.
Even the users are made and created on the backend.
My Problem :
How to use 3rd party apps within this system, that heavily depend on django models/ORM ?
Is there something that can provide some bridge between the REST API resources and the ORM?
How can this problem be dealt with ?
Update
DRY principal seems to be failing in this situation.
Probably things have changed since this question has been originally posted. Now there are a couple of interesting related questions on StackOverflow about this topic.
To code yourself a solution as explained in this answer, you can create an external service layer (aka services.py) and write there the logic to access the external resources. Your views will consume this layer, and make the proper actions. There are other questions that provide help on how to pass information from the original request received by the django-view to the external service like this or this
There is also a django app that takes this situation into account as explained in this answer. django-roa uses the Resource Oriented Architecture paradigm to solve this.
I'm facing a similar obstacle with a new ecommerce project.
The project is a front end to a full-fledged store management software (CMS+ERP+CRM). It needs to use the master product database, but have its own entries for product reviews, ratings and so on.
The initial thought was to make a cached copy of the master database. The website will benefit from fast loading times for the cached items, but the implementation is not trivial.
After some considerations, the selected approach was updating the website's DB from the management program. This way the website's copy will always be correct, and most of the implementation doesn't need to worry about REST services (it'll still be used for user registration, shipment tracking etc.)
In your case, where you can't have the service update your own database remotely, you need to come up with a mechanism that allows you to refer to REST recourses like regular models, and that caches them in the background.
Important note: research for a way to make sure the cache is always correct (non-dirty)...
I'm not sure I completely understand your question or requirements. The way I am reading it, you have a primary back-end which is basically a black-box, and you want to use some 3rd-party apps in your project which use the Django ORM.
I am unclear as to why there would be a need for being able to have a two-way synchronization between the two data-stores. The users of your project would be returned data from your primary back-end, and from the project's ORM.
Since you are concerned about saving the "ORM" data in your primary back-end, maybe you would consider creating a Transaction Middleware that would fire any time ORM data gets updated, which could serialize the structure being saved and transmit it to your REST API. This REST API, I assume, is able to accept arbitrary data structures?
You'll probably at least want to use some form of middleware, and maybe a utility module/class to help form the "bridge".
I want port some my Python scripts into web apps so that others can use it and I'll use some sort of web framework. I've been playing around with Django lately but it doesn't have the basic user registration, email verification stuff built in and one would probably end up using django-registration.
Almost all web applications require you to create an account, verify your account by clicking that verification link in your account and so on. One would save a lot of time if he could just skip past the part of setting up authentication, verification, the usual log-in and log-out pages and get to part of doing the "core" part.
Has anyone come across a pre-configured Python web-framework (Django would be nice) that does the all usual basic stuff? Django has that contrib.auth bit you can add django-registration
(I hope this question sounds reasonable.)
Thanks.
Take a look at Pinax ( http://pinaxproject.com/ ), which consists of a set of Django apps that take care of some of the most common tasks. Including the user registration one you outlined.
However, this is actually not very difficult to build. You are right, most sides need it, but implementing it even from scratch is pretty easy.
web2py take a look at Access Control Chapter in http://web2py.com/book