1

https://stackoverflow.com/questions/10941249/separate-rest-json-api-server-and-client

In light of this post, I wanted to ask questions regarding Django and specifically the implementation methods of getting one of these client side technologies to work with Django.

Currently, I have a backend that is setup that uses Django Rest Framework to serialize the data. My problem though, is I'm not sure how to get the client side to access the backend.

Django is a MVC framework. Originally I thought that I could just take out the View, and just implement the model and controller. Then, I would write complete separate View code so to speak using Backbone/Ember/Angularjs. Then the client would access the REST resources. How would I combine these two later if I wanted to deploy this to Heroku? Heroku only takes a whole Django application. How can I get the client code on there as well then?

The other option, which I've seen before, is to NOT take out the View completely, but to use Django templates WITH Backbone/Ember/Angularjs. Then, I can just simply put these js files in the "static" folder so to speak. But then that seems weird, because then I'd have a View on the server side (correct me if I'm wrong), that accesses my own REST resources. I tried this, but for some reason even though my page retrieves the javascript files, it does not seem to be working as expected.

  • a general advise: it seems that most of your problems arise because of names. forget about naming things ("this is a view", "this is a controller", "this is MVC"...) and focus on the implementation. – Javier Oct 4 '13 at 19:16
2

Quit thinking in terms of MVC. MVC alone only describes the interactions well if everything happens on the server-side. You need to think at a higher level of abstraction. For example, Data Layer (ex database), API layer (ex server-side), Client Layer (Webapp, IOS app, Android App).

A basic SPA works on the premise that the whole site runs on one big HTML file. Reloads don't require a round-trip to the server because you're basically showing/hiding different sections of code.

In practice that's not necessarily true because the framework (ex Angular) can pull template partials and data from URLs in the background. It sounds like you understand this much but can't figure out how concerns should be separated between server/client.

For templating, do it the same as you would in Django. Except, instead of loading the files from a local directory you fetch the partials from the server.

For generating views that include data you'll need to make a controller that can fetch the data and use it in the view partial. There are many ways to go about this but the most common is to simply create an API on the server-side that accepts data requests and responds with the results in JSON.

In MVC terms. The server and client will both still use models, views, and controllers:

On the server (ie the Data API). The models are the database/storage access classes. Instead of generating raw HTML the views will be used to format/serialize data for transfer. The controllers work out the messy details between the models and views.

On the client (ie the WebApp client). The models are the functions that handle fetching and deserializing data requests. The views are your html partials that get parsed into static HTML. The controllers /directives manage combining the two.

Can you still do HTML generation on the server-side? Of course. How much work you decide to do in the client vs server depends on your goals.

Then what's the benefit of client-side frameworks? If your goal is to create a SPA, then frameworks like Angular are a much more robust option than the alternitives which would consist of firing off a bunch of AJAX requests, then plugging it into the DOM using something like jQuery.

What's so special about client-side frameworks? Nothing really, they push the responsibility of HTML generation into the client. Instead of splitting HTML templating and dynamic manipulation between the client and server you can now do both in the client. It provides a cleaner separation of concerns and reduces load on the server.

If you need a data layer that can be accesses by multiple platforms (ex IOS, website, Android) then you've likely isolated the data requests into their own API already. If you have that done already, pushing the client-side code to the client makes sense since you're already doing that for the other platforms.

Simplifying the server to just a data layer makes life a simpler for those who develop on multiple platforms. Client-side frameworks made the process of fetching data and generating HTML dynamically on the client much easier. If your goal is to build a SPA, using a framework will provide a good scaffold to build on.

The major downside of client-side HTML generation is that it relies on JavaScript and most search engine webcrawlers are too dumb to use JavaScript. That means, if you have a content-heavy site you're going to have a bad time trying to get search engines to index your content. There are hybrid approaches to conditionally load content generated from the server to webcrawlers but they add another additional layer of complexity so the tradeoffs likely outweigh the benefits.

1

In order to get this type of app to work, you need to firstly go more in-depth into how the API setup works. APIs are different to the normal apps you can build in frameworks like Django or Rails (even though there's elements of APIs in these frameworks).

In order to explain a bit more, you can run your client-side JS framework being hosted on a static host (something like: http://www.divshot.io/)

You can then interact with Heroku (your backend) via API calls ('GET', 'POST', 'UPDATE' requests). This interaction would normally occur through something like JSON (where the elements are 'pulled' from the API, the client 'does something' to the element and the updated element is 'pushed' back via the API - making the database update).

Take a look at this question I asked a while back:

https://stackoverflow.com/questions/17760128/is-a-restful-api-and-a-backend-service-like-parse-the-same-thing

And also take a look at this guys tutorials concerning APIs:

http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/

These will help you somewhat in getting to understand APIs (those tutorials are especially useful).

If I remember from those tutorials, you can host your static client-side JS framework together with your backend on the same setup.

Just ask the guys at Heroku to clarify that for you, as I'm sure it will be possible to host the static JS/HTML/CSS on the same setup too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.