I am designing a scalable web app. I have APIs (Django Rest Framework) in one container instance, Web App (Django) in another, Database (Postgreql) in another and finally CDN in another (Azurite). I wanted to decouple API since mobile apps will use the same - eventually.
Question:
Where do I keep ORM in this scenario?
If I keep it part of Web apps, then how do the APIs recognize and use
the objects?
Or, if I keep them part of the API services, how do the front end
(web apps) understand the objects?
I'd suggest you keep your DRF code with the rest of Django and containerize them together.
As for the ORM, what matters is the container for Postgres. You cannot tear apart, say, models into a separate container.
To summarize, you can have the following containers:
One for DRF and Django
One for your Database layer (Postgres) for instance.
And one for your CDN.
Needless to say, you could containerize your webserver separately as well.
Related
I wanna to write e-commerce website on django.
My project will have two DBs:
PostgreSQL (For storing users data, django tables, orders handling etc)
MongoDB (For storing Products and their categories)
Django works well with Relational DBs, but working with NoSQL DBs in Django it's so painfully.
FastAPI has good NoSQL DBs support.
And I wanna to use Django and FAST API in one project.
If you have solution of my problem, please drop me a link to solution.
Maybe will be better if I'll use them separately (1 django server and 1 Fast API server) and
frontend will request data from 2 different servers?
Django REST with SPA "within" or completely stand alone?
I'm diving into a new project where I'll try to build a SaaS web application and I've set on using Django Rest (with Postgres to utilize schemas) and React/Vue on the frontend.
What I'm unsure and what I can't seem to get an answer to is the way people structure these frameworks. E.g, on https://www.valentinog.com/blog/drf/ the author writes:
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)
And here are my advices.
If you’re just starting out with Django REST and React avoid the
option 2.
Go for option number 1 (React in its own “frontend” Django app) if:
you’re building an app-like website
the interface has lot of user interactions/AJAX
you’re fine with Session based authentication
there are no SEO concerns
you’re fine with React Router
Why is this beneficial, and is it actually different from having a stand alone rest api and a standalone SPA? The reason I wanna use Django is so I don't have to worry about authentication and authorization, and I also plan on utilising the admin panel - will this "not work" if I were to use two completely standalone applications for the backend and frontend? (e.g django rest with the sole purpose of exposing the api and the frontend to consume it).
What alleged benefits do I get from having django rest and SPA in the same "root" project
I'm creating a Django project which involves the use of a REST framework (using DRF) in one app, and a web-based interface in another app. The REST framework uses the default session engine, which I believe is through database storage, in order to track user metrics more accurately. However, in the web-based interface, I want to use the cookies engine to provide simple authentication services.
Is there any way I could use two different session engines in two different Django apps, under one project?
I am developing an application which is used by multiple clients and the main goal of the app is to be used online. But a specific requirement is, it should be able to work offline too (only for a single client(s) in an emergency situation and for short time - 24 hours maximum). now I am using Django REST framework for backend and Jquery/AJAX frontend for GET and PUT etc. requests which update PostgreSQL DB on the backend. Now little research on the internet suggests the I should use PouchDB on the frontend and/or CouchDB on the backend. But my questions are:
Is it really possible?
If yes, then which DB should be used for the backend database?
When the offline client become available online, how we can synchronize the data generated online?
Can we cache some data on clients machine for offline availability purpose?
Is it still possible to use PostgreSQL for the backend? (I really want to use it !)
I want to use django framework to write a web site with static/dynamic pages (I will not be using angular/react - i.e. SPA technology) but I also want the web app to serve as the backend for a mobile app.
What's the best practice here? Can Django alone be used for it?
Will I need to use Django REST framework?
If you could recommend some specific modules to keep the app as simple as possible and avoid DRY code. That'd be great.
Thanks.
You have the right pointers in your question already.
Use django-rest-framework to create a rest service, create your web app in django to consume that service, create a mobile app to consume the same rest service.
In general, once you have a rest service, you can build anything on top of it. Just consume the service from whichever platform you want to build for.
I hope that helps.