JavaScript for Line of Business Applications

If you’re following the latest trends in the web development world, you might have noticed that the last years the popularity of JavaScript increased a lot. Lots of frameworks became popular like Google’sAngularJS, ember.js and of course Backbone.js.

One of the first of these “big” frameworks was Backbone.js. JavaScript code before that time was usually unstructured, contained a lot of spaghetti code and was hard to maintain.
Backbone.js gave you the possibility to follow the MVC (Model-view-controller) design paradigm, or in their case, MVP (Model-view-presenter).

Backbone.js gave you the possibility to divide your application in logical parts andprovided data binding. Only that wasn’t enough of course, because applications needed more components like:
* A module system
* Templating
* Data binding
* Data synchronisation
* Widgets
* Testing framework

And so, other frameworks were born, like: RequireJS, CommonJS, Component, AngularJS, Twitter Bootstrap, Flight, Hogan.js, QUnit, Jasmine, … (and I can probably go on for another hour).

As I’ve previously explained, one of the biggest hurdles to jump when getting started with Ember is authentication. Not anymore! I’ve put together a simple architecture that provides session-based authentication in a relatively small amount of code.

If you Google “Ember authentication” you’ll likely get a handful of SO posts and an even smaller handful of blog posts almost all of which implement some kind of token-based authentication, usually relying on Rails or Node for authentication. This requires you to perform a back-and-forth exchange with the server to authenticate credentials and receive a token. You probably have to store the token in some kind of manually made cookie or local-based storage, and you have to remember to consistently provide the token whenever you access a restricted resource.

Session-based authentication is a lot easier! First, the server-side mechanics for session-based auth are entirely built in to Django. Second, because the majority of the work is done server-side, there is little required of you in Ember. Finally, using session-based auth instead of token-based auth makes SSL a little less of a necessity since you’re not flinging naked tokens around with every request.

REST purists might argue that session-based authentication is technically not “stateless.” The trade-off depends on project requirements and personal preference. For single-page web applications, I can’t think of any practical downsides.

In the 2 previous posts we built a backend API with DRF and a client with AngularJs.
In this part, we will add authentication and permission to our app. We will add some restrictions on who can edit and delete posts.

* Authenticated users can create blog posts
* Posts are tied to their author (edit/delete permissions)
* Posts are read only for unauthenticated users

A REST API allows your users to interact with your website from anything that can send an HTTP request. In this post we will create a RESTful api in Django using the Django-Rest-Framework. And we will access this api using a client developed under AngularJS.

To utilize the API developed in Django, we are going to use $http & $q services in Angular. The $httpservice is a core Angular service that facilitates communication with the remote HTTP servers via browser’s XMLHttpRequest object or via JSONP. $q is promise implementation that comes with Angular.

In this article I'll showcase basic ember features and ember application development process for a Django-Tastypie-Ember application.

As you can read on ember website the framework has few layers, similar to Django or other frameworks. I won't repeat what's written there. I'll just give a quick overview from a Django developer point of view.

tastypie is a handy app that will make an REST API for use to use in ember application. To make a Tastypie resource we first need to have a Django model. When we have working Tastypie resources we can start creating models in ember application. Data aspects in ember are handled by ember-data.

At first many things in ember may look like magic (events and asynchronous actions), but when you look how this basic app is being made and how it works - the magic will become clear (or you will become a sorcerer which is cool anyway :)).