I'm trying to wrap my head around combining a client-side framework like AngularJS with Django. One thing that's really confusing me is the issue of routes and REST.
I've been trying to read a lot about it online, but documentation is limited, especially in terms of Django being combined with Angular (little snippets here or there). I understand that I need to add a REST framework like TastyPie to make a robust REST interface in my app in order for Angular to plug in and grab resources.
However, I'm confused as to how to properly map out my routes in such a way that (1) my server-side app can render my single-page app (SPA) with angular plugged in (2) routes that are supposed to load information/render templates (angular) and retrieve data from the server (django) don't conflict. Like if I have someone going on my website and doing site.com/user/1234 - that route is associated with both the Angular route and the Django route - except one renders a template and the other spits out JSON based on what is retrieved from the DB/server.
In addition, by using the REST api, do I forego a lot of the advantages I have in terms of having ModelForms being synchronized with my Models, etc? Is there any way to maintain this with AngularJS or do I have to look towards an AngularJS substitute.
The question isn't really specific to Django - just a matter of understanding the relationship between back-end and front-end in an SPA.
Routes are not duplicated between the back-end and the front-end. Your Django routes should be set up like:
/api/foo
/api/bar
...
and one single route that delivers a single page full of HTML partials, e.g.
/
The rest of the routes will be defined in Angular, e.g.
/articles/234
/blog/date/slug
...
The Angular controllers that handle those public-facing routes will in turn make $http calls against the API URLs and each will deliver one Angular partial. So there is no duplication, no overlap.
To the second part of your question, you can still use the Django ORM model relationships when constructing your API data, but yes, you'll lose all of that Django goodness when building the front-end.
If you build your API right, all of the data you need in each view will be fully present in the JSON feed that Angular consumes in that view. So you're using the ORM for back-end data construction, but you can't just decide to traverse a model relationship in a template without first preparing the back-end data to provide data for it.
Yes, it's a very different way of thinking of things, and yes it's quite a bit more complex than doing straight Django (or Rails). That's the cost of building a web app rather than a web site.
Related
So I just created a website's front-end using ReactJS. Now all I need is a backend database that I will fetch data from using requests.
The question is whether I need to render templates using my backend or just use my server to make requests (eg get, post etc)
PS. I will be using Django as my backend.
Thank you everyone who will help me out.
Doing both is recommended. Based on the requirements and use cases we must use both ways to render.
For example, Some products use initial html as a Server side rendered page with all essential data required inserted as scripts and so on. This helps in loading primary content faster. If we are not following this in applications that require data initially. Then it might take more time to fetch React chunks, scripting and after seeing an API makes request, and then getting data and then displaying the primary content. So when a page needs more data (like More API calls) then server side rendering might be a good way.
For other scenarios like getting user details, All these can be done using React.
No, because you will use DRF (Django Rest Framework) to communicate between frontend and backend. Basically you will write your own APIs in the views.py that will respond with JSON data, at least in major of cases this will be enough. So, you don't need templates, since template are really Djangos' frontend, that you will not be using at all.
But, this heavily depends on what you are doing and what is your setup.
I am not able to comprehend what would be pros and cons of the following approaches in making a single page backbone application using RESTful APIs from Django Rest Framework.
Render the whole app from within Django's template.
Serve the backbone app from another server ie node server. With nginx in the front for both servers.
Serve the HTML/Templates and JS from a separate CDN.
What are the things to take care ie points of caution in each strategy. Is there any other way to tie them up which I am missing?
This is a very broad question, and really it has nothing to do with Django or Backbone. What you're really asking about is a "thick-client" architecture vs. a "thin-client" architecture. In other words, having your user interface rendered on the client vs. having it rendered on the server.
First, allow me to recap a few things to make sure we're on the same page. The "thin-client" approach is the traditional/old school model, and the model Django itself is based on. The server renders HTML, sends it to the client, and whenever the client wants to do something it sends data back to the server and asks for fresh HTML.
In contrast the more modern "thick-client" approach lets the client render all of the UI. Whenever the client needs to do something it makes an AJAX request to a (presumably REST-ful) API, powered by a library like Django REST Framework. That API just returns the relevant data, and leaves it up to the client to render it appropriately.
There are advantages and disadvantages to both approaches, but the thick-client approach is becoming more and more popular because:
network transactions are faster: because your server is only sending the exact JSON you need instead of a mess of HTML, the "payload" of the response is much smaller
you can fetch all data "behind the scenes"; this makes things appear faster to the user, and lets you implement UI paradigms (eg. infinite scroll) that a thin client can't
the client/server relationship is simpler, because the people writing server code never have to even think about HTML or any other presentation logic; they get to just focus on the data (which, being server engineers, is probably the part they're most interested in anyway)
This is why a lot of companies (including the one I work for) have all but abandoned Django proper in favor of API endpoints served by Django REST Framework.
So, if you want to go with a thick client architecture, Django should never serve anything except the very first HTML page (and even that could be served by ngnix if you wanted, since it's just static HTML). After that you'd use a Backbone.Router and Backbone.Views to render your site. Whenever you need new information from the server you'd fetch a Backbone.Model or Backbone.Collection (with its url property pointing to your Django REST Framework endpoint).
I can attest that this whole approach works great; the site I work on is very complex, with many endpoints, and Backbone + Django REST Framework handles it beautifully. The only (slightly) tricky part is caching: in the thin client approach the browser automatically caches pages for you, but since there are no "pages" in a thick client (just AJAX responses with data) there is no automatic caching. This means that if you want to cache data you'll need to do it yourself, for instance with a Backbone.Collection devoted to that purpose.
Hope that helps.
P.S. Back in the day Django REST Framework didn't handle Django authentication stuff (ie. logging in/out) quite the way we wanted, so we wound up serving one other page, our login page, from Django. However I'm pretty sure the current Django REST Framework handles authentication stuff much better now, so this likely won't be an issue for you.
I've been learning Django for some time now, and I found this image helpful:
I'm now delving into Angular JS, and I'm trying to figure out how each of the components (Directives, Controllers and Services ?) interacts and if there is a similar 'cycle'. This blog looks like it comes close to answering my question.
But how is the picture different if we have a Django-Rest-Framework end point providing the books in the above example?
Do we want URL resolution from Django, or Angular? Or more answerabley, which takes precedent?
What is the general order that things happen in when we go to say localhost:8000/books ?
Does urls.py catch this?
urls(r'^books',angular_redirect)
If so what does that function (angular_redirect) need to render to get angular to respond?
Does angular routing catch this?
$routeProvider.when('/books', {templateUrl: 'partials/book_partial.html', controller: 'MyBookCtrl'});
So does this mean my controller then registers a service hooked up to say localhost:8000:/book_list.json and does that need to be registered in the urls.py?
How does Angular know where to get the DRF JSON, if we're wholly relying on angular for routing. I've seen this package that lets you use the django models in the angular JS, but I'm not certain if that makes the picture more or less complicated.
Apologies if this is overly broad, I'm very new and trying to get my head round some of the general concepts of these technologies. Any advice on narrowing this question so it's answerable would be appreciated.
Your question has a simple answer: Angular handles the front end and Django (and DRF) handles the back end, and that includes URLs. Users on a fully Angular-powered site should never directly hit a URL that is served by Django, except possibly for the initial page that serves the page structure and JS itself.
Apart from that, the only interaction between the two is when Angular specifically requests JSON from Django, via an Ajax call. That may well be in relation to a navigation event by the user, but just as equally could be triggered on a timed basis or via some kind of websocket functionality.
I am very new to the world of web development and MVC architectures. I am currently working on django which i believe is an MVC framework. if i am right, for a web application MVC implies
views is the front end
models is the backend
controllers are the glue between frontend and backend
well if the above is true and views are the only frontend parts what exactly is the function of frontend frameworks like backbone, angular? how exactly do they deploy the mvc concept? Also when building a simple blogging site which framework would be preferrable? and also are there instances of websites working on both frontend and backend mvc frameworks? please give examples. for clarification i went through this question: In the Model-View-Controller principle, what is the Frontend and what is the Backend? but couldnt understand fully. thank you
There is no one-on-one analogy of front- and backend and the MVC model. For example, the admin of a (Django) site is generally considered to be part of the backend - it is not the part of the site the user will see - but part of the admin is definitely the View part of the MVC model. Anything a normal web user sees and/or directly interacts with is part of the frontend, everything else is part of the backend.
Now what is the MVC framework used in Django? We have:
The Model: this is the part of the application that holds the state of the application. In Django, a big part of this is the database and it's abstraction layer, the Django models. Other parts are user sessions and the request variable.
The View: this is the part of the application that presents the state of the application to the user. Django views and templates are responsible for this. Any data you see when you open up the website is the View part of MVC. The overall presentation is also part of this.
The Controller: this is the part of the application that represents any action you, the user, takes. Django is not truly a separated MVC framework because the View part and the Controller part are so tightly interwoven: any link, form or button you see on the site is a controller. It tells the site to do an action, such as present a different view (e.g. a link), or change the state of the model (e.g. an edit form).
What about Backbone or Angular? Why do you need two different MVC frameworks in a single application?
Django is a server-side framework. Every action happens on the server. If you click a link or submit a form, you send a request to the server and the server sends back a complete, static response (static in the sense that the page doesn't change once it's in your browser). You can't use Django to use logic client-side, as it is a python framework that runs on your server, not in your client's browser. Instead, it's Javascript's job to add any client-side logic, e.g. to reorder a list of items on the page or to dynamically add a new one. Now each page can be seen as some kind of mini-application.
Backbone and Angular are examples of MVC frameworks for such client-side applications. It supplies the client-side application logic that a server-side framework such as Django lacks, and surprisingly the people who like an MVC framework to develop a server-side application generally also like to use an MVC framework to develop a client-side application.
Django is a kind-of hybrid version of the Model-View-Controller model. The Django documentation generally describes it as a Model-View-Template model instead. Generally, the template (Django HTML with template tags, etc.) is generally matched to the normal View, providing the user's view in the way of web pages. The view in Django generally takes the place of the Controller, as it works between the Model, taking data from databases and defining new objects, and the View, which in this case is the Template. The Model is the same as normal in Django, providing the definition for different objects. So while the Model-View-Controller is normally the model for most languages, it is more so a Model-View-Template model, with the View being different than it is normally. Read more below:
http://jeffcroft.com/blog/2007/jan/11/django-and-mtv/
I am looking at Django, and patterns for web development.
What I am favoring at the moment(2014-01) is.
Use Django (restful/json) as the MC, Model/controller, or backed data and logic.
The controller part in Django refers to business rules and access control.
then use a javascript framework and bit of html as the client side code. View/controller.
In practice, the client/browser loads a javascript program, View/controller that then does restful queries to the backed model/controller
I'm in a process of migrating Rails project into Django. Rails project was built using restful routes and it never touches the database. Instead, it simply redirects to different methods which all call an external service with the specified action method. Now, I have found a number of frameworks for django that provide restful capability plus a bunch of bells and whistles, but it's an overkill for my current case.
As an alternative, I can ignore action method in urls.py by simply providing a regex to validate urls and then parse the request method in views.py, redirecting to the appropriate method. Is this a way to go or are there any other approaches that I can look at?
Class based views look like the idiomatic way to organize restful view functions by request method.
Django snippets has several simple example implementations.