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?
Related
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.
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 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.
We have a project that was developed by using Django, and we want to develop a mobile application out of one part of that project(not entirely the whole project).
From my own understanding, RESTful APIs are used to be the backend of mobile applications. So we want to build this API as an app inside the django project using Django-RESTful-Framework.
So my question is, is it okay to build an API inside an already made Django Project?
Because the RESTful API will need models of that project. For now, we already have a problem of accessing the api endpoint from the mobile app because the django project we developed was using sessions and it responses with 403 forbidden.
ABSOLUTELY! DRF is an awesome package, and if you need to power a mobile app through an API off the same models, this is the way to go. Of course it is an opinion thing, but I think that DRF's strength is that it is easy to get up and running with, but allows some really in depth control when needed.
If you are getting a 403, it is tough to say why without seeing any code. Take a look at this: http://www.django-rest-framework.org/api-guide/authentication/
I have just created my first token based web API with Django-Rest-Framework and it has worked really well for my mobile applications.
I am about to start creating a website based on Django, but I would like to reuse as much of my API code as possible.
The options I can see are:
Create a basic Django application that consumes my DRF API, would have to add basic auth to my api?
Create a third application which contains all my models and logic and then import the code into the API and website application.
How do you normally approach this kind of code reuse with Django?
This answer is based on my personal approach on the problem, both on industry and academic scenarios.
I value software decoupling. As such, I want to build smaller components, as reusable as possible. While presented with a similar problem, I've built the following components:
Django Rest Framework with authentication based token and complete REST API for all models;
Mobile application that interacts with the server using REST;
Web Application (in my case with AngularJS) that interacts with the application using REST.
This approach allows to have different teams working each on their own (backend, mobile, web). I could enumerate tens of advantages of adopting such approach, but I've paved the way and you can consult literature if needed.
Good luck