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.
Related
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..
I want to use Django Rest Framework as an API and am looking for a way to "couple" the frontend / HTML/CSS/JS to it.
To put it in perspective, I am used to the way Django "usually" does it, by naming HTML templates and 'rendering' them when going to a particular URL.
Now, with DRF, it appears that this functionality has fallen away and everywhere I look it's just "react.js or vue.js" as the answers to consume the API.
What are my options for the front end? Can I not just do it all within the 'usual' Django framework, simply, as it was done before. And why do no resources talk about this?
Thanks, let me know if you require further info.
DRF is just additional layer for Django which help to implement API. You can use Django for render html on server side and serve it to browser. You don't need use DRF for it. But if you assume that you frontend app will be interactive, dynamic and complicated then it is not best way to solve it.
More popular approach suggest to separate it on frontend application (react or vue) and backend with REST API for interact with. It allow move all things related with UI on frontend app and only keep state on server.
By the way Django was developed for generate html on server and for site like this https://www.washingtontimes.com/news/ but world changing. Resources talk just about popular things
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)
I would like to build a new application using node.js but it requires quite a bit of backend management that I would rather not have to build. I have some existing code in django and really like the built in Admin interface for handling the backend management.
Is it possible for me to use something like nginx to direct all traffic to my node.js application except when the url path starts with /admin in which case it would direct the traffic to django?
Alternatively is there something like the admin interface for any of the node.js frameworks for certain databases?
Thanks.
Yes, you can do that.
It might be easier to just put your django admin app on a subdomain, django.example.com.
I'm using Django admin interface with a legacy PHP application. I found out I could build a nicer admin in just a few hours, than the special built one. The frontend is still obviously using PHP and the old code, but I just swapped out the entire admin backend which is now run on django against the database.
It's very nice indeed.
If you are already using Node.js, you might want to look into node-http-proxy which can redirect requests to different places based on the route. It's very easy to setup and runs very fast from my experience.