Hello I am tasked with translating a current Excel tool to a web application. I decided to use Python and Django. Lately I studied the Django REST framework. I have the following related questions.
Is it for such an application a good idea to first write a web REST API so that I
firstly only need to focus on the backbone of the web application. I.e. implement the PUT, POST, GET and DELETE methods and the Django models.
The second step would be to implement the user interface... But if this is a valid method how can I reuse the REST views??? I followed the REST tutorials, but they don't show how to build a nice slick user-interface on top of the REST API.
Since REST views inherit from Django, I think it's maybe not such a good idea to write a Django view which inherits from a REST Apiview? Or can I directly use an API endpoint in a template. If so where can I get some nice examples?
Writing the back-end separately using Django REST Framework is a great idea.
There is a strong architecture based on the idea of decoupling the back-end from the front-end. After you finish the project's backbone, as you are calling it, you can start creating you front-end but your don't have to use Django template rendering in that case.
You can take the pros of using REST APIs and you can use one of the good front-end frameworks or libraries as Angular and React.js.
Another advantage of this that the same API can work with mobile development and so on.
So you develop one back-end and multiple front-ends depends on your need.
Also you can read a discussion about your question on Quora: https://www.quora.com/Why-does-it-make-sense-to-separate-front-end-from-back-end
Related
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 am building a project where I have 2 approaches to follow -
Either I can create APIs for all operations and call them from my frontend which can be in Angular.
Or I can use normal Django views and template.
Question: what is the best approach to follow and what is the performance impact of them?
Go for Rest API, that will make your life easy if you have plans to integrate that with other Applications (e.g. May be you would like to create Mobile App in future)
There are many factors, that play into this, however if you already have a front-end built with Angular, there is a strong case to be made for the approach of using a Django Rest Framework-based API. Some advantages are:
Encapsulation facilitates testing.
API resources are reusable, should you need similiar functionality in some other appliication or front-end
If you seperate these components you can more easily change either one or the other, if your requirements change in the future.
I would go with the API…
I am setting up a server for my android chat app. It is a pure group chat i.e. each message will be sent to multiple users and not just a single user
Since I have a background in Python, I would prefer to pick a python based web framework.
So as I was searching, I came across "Django" and "DjangoREST". After reading a lot about them, it seems that DRF (Django Rest Framework) is a RESTful implementation of Django and will let you make applications that are light and scalable.
Since this is for the first time that I am setting up a web service, I can not relate or understand this completely. Also, I feel that what I want to accomplish, could be accomplished on either of the 2 platforms.
Therefore, it will be great if some one could share some very basic and key differences(if any) between the 2 frameworks. So that I can decide which on to pick up.
There are no differences. Django is a web framework and Django Rest Framework makes it easier to create REST services in Django itself.
It doesn't replace Django. It adds to it.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
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