I've made a project using Django and Bootstrap (I plan to use React for the frontend). Then I started building REST API with DRF and it seems that my DRF views are pretty similar (if not duplicative) to my original Django views such as DetailView, UpdateView and etc.Now I wonder if I can keep my old views or should I completely replace them with DRF ones? Or should I use DRF views for CRUD and keep particular Django views?
And another qusetion: am I right that when working with Django and DRF Django becomes just an ORM provider also responsible for business logic, authentication and some other features?
Thanks.
Django is a fullstack web development framework. Here you can progress in different ways. You can use Django and ReactJS without having to develop any RestAPI. It depends on how you approach it with ReactJs.
Do you want to develop the frontend entirely with ReactJS? If so, you can develop your backend directly using DRF and consume APIs on the frontend only with React.
While developing a full stack with Core Django, if you want to make the Frontend dynamic, you can use Django and DRF together, or you can develop APIs without using DRF.
You can use DRF and Core Django together for different scenarios, or you may only need one of them. It depends on you and your project.
Edit for second question:
Django Rest Framework requires Django. Also, with Django you can do everything DRF does. By writing more code of course. This process provides many conveniences with DRF; like authentication modules, json serializers..
Related
I'm not sure what might go wrong when I have to integrate a django API (built using JsonResponse and without extra frameworks) with a frontend, in this case, Next.js.
I built a django API using JsonResponse (void of DRF). I want to build a frontend client with Next.js that would make API calls to my django API. My questions are:
Will I have to run both django and next.js servers at the same time to execute the full project?
I think I would face some challenge with csrf token, what other challenges may I face having built my API without an API framework as Django Rest Framework?
It is almost always a better approach to treat these two as separated as possible. I'd go with completely separate repos, hosting etc...
I think the biggest advantage of using DRF is the validation. DRF has nice ways to handle request data validation. Your views will look much leaner, because it will save you the trouble of writing much boilerplate code.
I'm just wondering since Jquery is used less and less and instead of classic use with Ajax, if it is possible to let for example React or Vue handle all of the functionality where Javascript would be needed with DRF in one hand , and consider all of it as statics.
And in the other hand, keep working with Django and regular templates.
i'm just asking about the possiblity to do so.
Yes. There are many tutorials available for using Django, some with Wagtail as a CMS, with DRF as the backend. You can use a single template, and Vue or ReactJS for the front-end.
Here's a workshop video that might help get you started from the folks at Learn Wagtail: https://www.youtube.com/watch?v=xUWd3o6z2bk
(I chose Wagtail, because it is a popular Django CMS with DRF API endpoints out-of-the box.)
I have read a couple of articles about using new JS frameworks like Backbone.js or Ember.js
I have come up to this statement:
If I use a JS framework like Backbone.js/Ember.js, I then move the logic from the back-end (Django) to the front-end.
Therefore, will Django actually be used only for its Models?
Does that mean that Django Views and Django Template are not needed anymore and the Django back-end is kinda turn into a "basic" REST API that will be consumed by the front end.
Do you agree? Is it then the purpose of Django in this case?
Is turning the django backend into a REST API one of the most suitable use case when using a framework like Backbone.js/Ember.js for the front-end?
Thanks.
Django is perfectly fine to be used this way, you still get the admin, the models, the orm and all the third-party plugins. However, it isn't blazingly fast, so if you're doing simple document level, non-relational REST mapping, you might wan't to look into node.js and mongoDB for instance.
If you're sticking with django (like we are, we like the structure it gives us), you can use one of the REST plugins:
Django Rest Framework A perfect match since DRF 2.0, under very active development!
Django Tastypie (checkout backbone-tastypie.js for integration)
Django Piston (might be a bit stale or has development picked up lately?)
If you only want to work with frontend development, checkout the Backend-as-a-Service places like cloudmine.me or firebase.com that handle all backend stuff for you, for a price of course.
Django may seem unnecessary once you start thinking about single page solutions and Javascript applications, but if you want your site to be 'fail proof' it wouldn't be impossible to develop both a client side Javascript version of the site as well as a backend django side incase the user, or your site's javascript, fails at some level. Of course this requires creating your site twice, and probably isn't needed in the age of modern browsers, but such would be one of the few instances where you would mix the two for a complete solution.
Yes, that's about it. You can use it to manage authentication to resources and such and maybe use a main view for your application but you won't need to use the server side templating since these frameworks are made to work with json/xml response.
That's why a lot of people are moving to lighter backend/backbone or ember combo instead of a complete solution like django. You can also use your django for caching json response which makes your application appears faster.
We are doing that and use django-piston to make it easier on you.
Normally you make your entire website under Django and only one page will be a "single app page" using backbone.js, usually that page is a very interactive page, with lots of small updates that occur frequently and need to be shown very fast to the user. This page, because of the large number of changes and user interactions is constructed on the client-side so that you are using his PC resources and not the server's, the rest of the pages can use django because it offers you a very stable and secure framework for the server-side
I understand that full django can be used out of the box with CloudSQL. But I'm interested in using HRD. I'd like to learn more about what percentage of django can be used with nonrel. Does middleware work? How about other features of the framework like i18n, forms, etc. Also does nonrel work with NDB?
The background here is that I've even using webapp2 and before that webapp and find them great until your project gets bigger. So for this project I'm interested to reevaluate other options.
The big limitation is that the datastore doesn't do JOINs, so anything that uses JOINS, like many-to-many relations won't work.
Any packages/middleware that uses many-to-many won't work, but others will.
For example, the sessions/auth middleware will work. But if you use permissions with auth, it won't. If you use the admin pages for auth, they use permissions, so you'll have some trouble with those too.
i8n works.
forms work.
nonrel does not work with ndb.
I don't know what you mean by "until your project gets bigger". django-nonrel won't help with the size of your app.
In my opinion there's two big reasons to use nonrel:
You're non-committal about App Engine. Nonrel potentially allows you to move to MongoDB as a backend.
You want to use django packages for "free". For example, I used tastypie for a REST API, and django-social-auth to get OAuth for FB/Twitter logins with very little effort. (On the flip side, with 1.7.0, they've addressed the REST API with endpoints)
According to the documentation, an app is a module which deals a well defined operation.
Is it correct to think about an app as a REST-based service? or is it mandatory to use some framework like piston or tastypie to create a RESTful web service around an app?
Generally, no. Django app is really just a python module, with some interfaces to django internals like models, urls, admin discovery etc.
To implement REST, you still have to manage network communications via views, and this is where you either write your own code or use the help of tastypie/piston/etc.
Please do have a look at django-rest-framework, I just stepped over from tastypie to this new framework, works great!
http://django-rest-framework.org/
Especially the class based views and the browsable api! and may other advantages (e..g. to upload images)
And to answer your question:
The rest-base service is an extra entry to your webapp.
I made some api's for some projects using the django-rest-framework, most project members were surprised they got a webapp as an extra, while it was actually the other way around. You make a django app (with views models and urls) and on top off that you make the api.