I'm used to Django and already developed website with a whole Django or with Django API + React.
For a side project, I'm thinking about creating a Django project with 2 apps:
Django API 2) Django Front.
I absolutely want to decouple front/back to be able to reuse the API in the future, and I like the view system from Django.
Is my idea making sense?
Edit 1:
To clarify.
App 1: Django API serving JSON.
App 2: Django App using API calls in the controllers to generate the views.
Edit 2:
I did a proof of concept and it works like a charm.
The only drawback is that I have to use Cookies to store the JWT token and maintain the session state, which is not convenient
it is possible, but completely wrong with idea.
How it possible. Wrong version:
Try to remember, how we can create integrate test for our view. We Should create client and send request to Django to your view-url with args kwargs querystring e.t.c.
In response you have already answer. Try to imagine: part with client - is your Django front, requested part - your backend.
The same works not only in test, you can create request to ask something on the completely other server.
Redis/MemCashed e.t.c. (pattern sender/receiver) Wrong version:
The Front Django speaks with Backend through Third part application. It can be faster.
"Pythonic" version. Right in your case:
You can create Backend Django part like a library with views as interfaces.
Frontend Django part is completely standalone, it import an use interfaces from library, which is your "BackEnd Module".
If you want - you can use "BackEnd Module" everywhere as import, or you can start it as server and ask info per requests.
Completely independent in this case means, you can install "BackEnd Module" without "FrontEnd Module". "FrontEnd Module" can be installed standalone too and it should take from settings, which interfaces should be used as data-source.
I hope, i am right understand your question.
You could definitely separate front and back, remember, django just creates endpoints and consumes them with its own views, you can even use both.
Here is the documentation for django views: https://docs.djangoproject.com/en/4.0/#the-view-layer
You can use a librarie like React as frontend and connect to your api(django app) and use both.
Related
I'm trying to setup a project using Django for backend and React for frontend. The project has several screens, a lot of information in DB and images generated by the backend, and will include some authentication and user permissions for different screens.
According to what I found - the best way to do it is having Django render an html file:
def index(request):
return render(request, 'frontend/index.html')
which references a .js file:
<script src="{% static "frontend/main.js" %}"></script>
Which is created using Webpack.
This main.js retrieves the data it needs from Django using a REST api:
fetch("...some Django endpoint..").then(response => ... this.setState(...retrieved data...))
Unlike when just using Django for backend + Django templates for frontend where the backend can just send the context directly to the template:
def index(request):
context = {'information': .... retrieve info from DB}
return HttpResponse(loader.get_template('bla/index.html').render(context, request))
and the template can use this info directly, without referencing the backend again:
{% for bla in information %}
I'm wondering if it is a reasonable setup?
It seems excessive to have the frontend use REST for retrieving each piece of information it needs and the backend exposing another REST api for each part of data it needs to supply (Instead of just pushing all of the information to a single dict and sending it over along with the template),
Also, it requires at least 2 RTTs to render the full page (which I guess usually is okay)
According to what I found - the best way to do it is having Django render an html file:
I disagree with this line. I would say it would be best to keep the react app and Django app totally separate.
I believe, the Django application should solely provide APIs and adminsite(maybe, depending on your needs).
And the frontend should be a standalone app which can be served through NGINX/ExpressJs/Apache etc.
There are several advantages of this setup.
From Django application's perspective, the advantages are:
Django will not be burdened to serve the Frontend. Use gunicorn or uwsgi to serve the Django APIs.
As Django will provide data through API only, it will provide clarity on how the frontend application will communicate with the backend. I know that you can send data using context when Django serves the react app, but this might cause confusion because of API and context's co-existence.
You can use Token based authentication, JWT etc instead of Django's own session based authentication, which have a lot of other advantages.
Freeing your frontend application from backend is the best thing can happen for the frontend. Like for example:
if you had Django to serve the frontend, you were almost forced to use session based auth(its not like you can't use other auths, but whats the point of having multiple auth systems)
You couldn't have used server side rendering with Django rendering the frontend.
Lets say, you are have no idea about how Django works, but you will be forced to setup a Django application in your local machine, because it serves the frontend.
You couldn't have used ExpressJs to serve the frontend, or use the advantages of using NGINX to serve those contents.
Deployment would be complicated if you have docker setup. In this case, you would have had to use one Docker Container to serve everything, else you could have used multiple docker containers to serve backend/frontend.
Lets say, you want to serve the Django application in one server, frontend from other server, but with Django tightly coupled with Frontend, you can't do this setup.
You can easily connect external RESTful API services without bothering about Django. Even you can use any other frameworks like Tornado, Flask etc(but DRF+Django ORM is awesome) to develop APIs.
There are some more generic advantages of having backend and frontend separated.
There is a fantastic tutorial which you can read on medium about setting up separate Django + ReactJs app.
You can use GraphQL, it has several advantages over REST, f.e.:
only one endpoint for entire app;
ability to fetch data with relations between them;
easy data structure modifications on both sides;
advanced client with cache/normalization/subscriptions/optimistic updates (I prefer apollo to relay);
can be used as datasource for static site generation (SEO);
you can stich other services/APIs;
... many more.
Using react Server Side Rendering you can get pages without additional requests - 'prefilled'/rehydrated, ready for interactions - better Time to Interactive.
Tutorial/demo: django-graphql-apollo-react-demo
I'm not sure if this is possible since an extensive search gave me nothing. Or I might be searching the wrong terms.
Now I have a few apps inside my Django application as follows:
--AppOne
--AppTwo
--ExtendedAdmin
manage.py
Now, AppOne and AppTwo use Django Rest Framework and its related Token Auth Mechanism. For the extendedAdmin, I'd like to use native Django Auth or even SessionAuth of DRF since I'm trying to add quite an extensive admin panel to the application. I've not been able to find a satisfactory way of customizing Django Rest Framework to work it's auth mechanisms only for certain applications. Is there a way to do this? If not, what should I be doing different?
So far, I know you cannot. Because django rest framework intercepts the url and then performs its own logic of token validation. But there are solutions that you can use to keep both Session and Token Authentication.
I am using this for all my projects -
I keep Session Authentication for all urls that will be accessed for normal browsing
and I use api urls with django rest framework to be prefixed with /api for my api urls
For example -
The Session Based login is at http://<host>/account/login
and TokenBased login is at http://<host>/api/account/login
The easiest way to make prefixed url for django rest framework is by using Routers - http://www.django-rest-framework.org/api-guide/routers/#defaultrouter
Example -
class UserViewSet(ModelViewSet): # just a sample view set
...
router = routers.SimpleRouter()
router.register(r'api/users', UserViewSet)
According to this StackOverflow post: DjangoRestFramework - How do I customize the frontend?
it says "Typically you want to put your DjangoRestFramework REST Api in something like /api". I'm not sure what this means, so I did some more browsing.
In this GitHub project: https://github.com/kevinastone/django-api-rest-and-angular there is an /example/ folder and inside the folder there is a folder called /api/ which has api.py and serializers.py. I've never come across a tutorial which ever told me to create an api.py file and to place an /api/ folder inside the app (it looks like the app is called "example" in the GitHub project).
I've watched this tutorial: https://godjango.com/41-start-your-api-django-rest-framework-part-1/ and it seems as if the instructor created an app called "api" which has serializers.py and urls.py. With that said, different tutorials show different things. What's the preferred way of creating a Django app which uses the DjangoRestFramework for a ReSTful API?
My end goal is to create a Django app with DjangoRestFramework and AngularJS on the frontend.
I'm sure you've already figured this out, but for other people that stumble upon this he's including his api as it's own django 'app', just like in the tutorial you mentioned. His file "api.py" is basically, for all intents and purposes, serving as what most tutorials call "views.py". But as it is where he declares the methods for his api, and not the applications views, calling it "api.py" is clear cut and makes sense. Doesn't matter what you call it so long as it's imported and used appropriately. The best way to make a rest framework is to use paths that are reflexive of their use case. 'api/post_images' for instance, would post an image and not post a comment or retrieve a user's profile information.
If you only have one rest api call, you may not be interested in holding your single api method in it's own designated file. But as your application grows the use this convention will prove its value.
I am writing a Django management command that visits a few pages, logged in as a superuser, and saves the results to a set of .html files.
Right now I'm just using the requests library and running the command with the development server running. Is there an easy way to generate the HTML from a view response so I do without actual HTTP requests?
I could create a request object from scratch but that seems like more overhead than the current solution. I was hoping for something simple.
Django has a RequestFactory which seems to suit your needs.
While it's not exactly meant for this purpose, an option would be to use the testing framework's Client to fake a request to the url - be sure to use client.login() before making your requests, to ensure you have superuser capabilities.
I have a medium sized Drupal 6 site running (around 5 million page views per month and more than 30K registered users) and I need to integrate OSQA, a Django application, with it. I already have many users, roles and permissions in my Drupal database and I'd like to point the Django app to use the sign up and login pages I already have in Drupal to give my users a single point on entrance.
I want to keep the Django authentication part because I think OSQA would work better. I also have performance reasons in mind, the Drupal site already gets a lot of traffic and has a very busy database and I think that using a separate database for Django would help.
After some research I think I could make the Drupal sign up and login pages call Django in the background to sign up or login to the Django app. I plan to do this writing a couple of views in Django, one for sign up and another for login, and Drupal would post the username and password to those views. Of course I'd need to disable CSRF in Django for those views and probably also post some secret key that only my Drupal and Django applications know about to avoid external sites trying to use this "unprotected" Django views.
I know that my Django application may need some user data from Drupal at some points and I'm planning on using the Drupal services module for that.
Would this be a good approach? Any suggestions?
Thanks a lot!
Are there any plugins for OSQA to expose an authentication service that Drupal can talk to? (OpenID or similar).
Alternatively, check out Drupal's ldap_integration module for an example of a module that uses an external authentication service. Consider that you will need to create Drupal user accounts for each login.
Finally, why not just build the essential parts of OSQA's functionality with Drupal? Seems like the key functionality could be replicated quite easily using Taxonomy, Vote Up and Userpoints/User Badges... potentially easier to do than shared authentication, especially on a large site.
I once created a very simple [sql_authentication][1] module, which you can probably simply re-create for a more recent version of Drupal.
The idea is simple: provide Drupal with an alternative authentication callback.
In that callback-function, just check against the Django database, and return TRUE if you think the user is correct.
You could look at how openid.module (in core) extends the user-authentication for a simple example.
If you can post to the Django form, you may be able to use drupal_http_request to handle the call to Django. After using the ldap_integration module for a while, I worked on a custom authentication module that calls a Java-based REST authentication API using drupal_http_request. If you're interested in the code, let me know.