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…
Related
I've been working with the django framework and mostly have been using html templates for its front end but im wondering whether i should switch to React if it's a big project? Alternativelyl, can i create a user interface application without using React as front end or is React / ReactRedux advisable when using Django?
Can you achieve greater functionality with React when manipulating the front-end as opposed to using views in Django?
Advice for when to use React does not have to do something with Django. It mainly depends on the complexity of the application that is to be developed. If you have, or will have a Web application with a complex frontend, containing many functionalities and quirks, which can grow to a large codebase, it is a good idea to use one of today's popular frameworks such as React, Vue or Angular. They allow you to divide the large codebase into components and manage them more easily.
So, the short answer is - if it is going to become a large and complex application, it is a good idea to use React. Otherwise, Django templates will be just fine.
If your application's frontend getting larger and larger and you feel that your are repeating too much html page for example , you might want to use a SPA and component based framework to reuse the components across the application.
If you want to separate backend and frontend code to acquire more maintainability and separation of concerns that might be the reason
If There will be more than one clients(Web, IOS, Android etc.) it is a good idea to separate backend code from frontend(client)
Frontend framework will bring more structure to your application therefore it will be more easier to maintain the project
Otherwise Django templates are good to build a fast project like a few form entries and an introduction page etc.
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
I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.
What are the pros and cons for using django related REST API packages such as tastypie, piston or django-rest for non-ORM calls over simply using views?
I don't think its really a question of whether the API resources directly map to models or not. Its a matter of these API packages abstracting away much of the boilerplate code that you end up doing like checking the request type, mapping to URLs, and serializing your output. Associating a resource with a model is simply one of many features, allowing you to more easily format the representation of the data.
While I can't really see this as an significant negative, I suppose using an API package does require you to conform to its specs and generally work within the realm of its features. But packages like piston or tastypie are so convenient, I can't really think of a real reason NOT to use them if your goal is to expose a RESTful api. You get so much for free. These packages also tend to include extra authentication functionality, and decorators.
Writing basic django views is just the same as rolling your own API. Either use a package for convenience, or roll your own if you really need something custom that they don't provide.
Besides REST to ORM call translations, many aspects can be handled for you by a good API package, such as being able to support multiple serialization backends, handling of authentication/authorization, caching, throttling and more.
If you don't expect your project to ever need these benefits in the future, going for hard coded views may be the quickest, however that tends not to be the case.
I am building a application that services users via a web front end, which I have chosen to use Django for. I also have to choose a framework/libraries to provide management of and abstracted access to a bunch of embedded systems that provide information the web user gets to see in one form or another.
I like the idea of sticking with a restful approach to access the backend application which provides the hardware generated resources. Does it make sense to use Django for the front end and CherryPy for the backend? Or should I just use Django for both and ignore the stuff I don't need in django for the backend.
I guess another way to ask, is what do I gain by using CherryPy as the backend that out ways having to know two sets of libraries/frameworks.
I don't see any real benefit, only added complexity in the long run. If you are using Django's ORM, you'll want to build the REST interface around that anyways. For building REST interfaces with Django I like using django-tastypie which makes it easy to build RESTful APIs supporting authentication/authorization, validation, various types of serialization, throttling, caching, etc. I also rather like django-piston, which is also quite popular.