Tuesday, March 25, 2014

When and why to use NODE.JS



Node.js ! 

The new kid on the block, has definitely been turning main stream. So, you must have heard buzzwords like async io, server side javascript, etc getting associated with the node hype. Some remarks from the sceptics as well - you cant handle dynamic javascript with your immature development workforce or node.js is ok for hello-world apps but not necessarily for primetime on the enterprise applications landscape.

Well heres my attempt clearing up the mist, with regards to node.js and related frameworks...

When to use Node.js

As very rightly pointed out by the authors of node.js, it is an excellent fit for DIRT-y applications. DIRT stands for Data Intensive, Real Time.

How do Java EE web apps work

Lets start out with a traditional Java EE web applications hosted on say a tomcat container, when a 1000 users concurrently access the web application, for each user request a thread is spawned by the web container. Each thread, does processing, passing control through, various application layers like view, controller, service, data access to finally hit a database or backend, get the relevant data and bring it back to presentation tier from where it may be formatted like an html response and sent back to the client browser as an Http response. The hundreds/thousands of threads running in the web container, ensure scalability of the application. But each thread contains synchronous method calls. Each thread is held up, while the sync call completes.The best to emphasize this is through a database call such as
ResultData data = personDao.updatePersonDetails(person);
 ( above call blocks till all DB rows are fetched )

it is not uncommon for many threads in such an application to be waiting for IO either disk io or network io (as in a database call). As a result one can clearly observe that hardly 10%-20% of cpu is utilized on the web tier, most latency is due to threads waiting on IO.

Can the above latency be reduced?

Enter Node.js with its aysnc io

Node.js at its simplest and most fundamental level prefers non-blocking function calls, through incessant use of callbacks. For example the above blocking database call can be simplified logically to the following async call:
personDao.updatePersonDetails(person, function(err, numRowsAffected ){....} );
Above call issues request to database driver for update but does not wait for results, it continues to next line of execution, and when the database update has been made, the callback i.e. the anonymous functiona gets executed, returning back the error if any and the number of rows affected by the updated.

Though the above difference between using sync blocking functions v/s using async functions with callbacks may seem trivial, if we adopt the async non-blocking function calling as the default way of programming soon things start adding up.

Instead of having 1 thread dedicated for an http request and having thousands of such threads, in node.js we have async functions, which do processing in bits and dont hold up a single thread. The node.js model starts exhibiting more scalability, due to non-blocking nature of calls in the processing stack.

Where are the benchmarks?

Well, consider this, apache webserver uses the multi threaded model whereas nginx uses non-blocking IO, it has been proven several benchmarks that nginx with its non-blocking io shows roughly 20% better scalability than apache webserver. So even for serving static content, we know, async io is always going to be more scalable.

Can Node.js leverage multiple cores? Is it fault tolerant?

This was another valid criticism raised against node,js platform in early days of the framework. We need to understand that node.js server has only a single thread available for the application' usage (there may be others for doing the server's internal housekeeping). Due to the above limitation, node.js processing runs on a single core and is also susceptible to outage since one thread crashing can bring processing down for all clients. Thankfully multiple node.js servers can be run on the same machine with a load balancer upfront. Or node.js modules like "cluster", "upstart" and "forever" ensure, node.js servers can be horizontally scaled and will have features like guaranteed uptime and automatic restarts, on crash.

Node.js for realtime apps

Out of the acronym DIRT, we already saw how node.js is a good fit for "data intensive" applications, well its time to talk about one more category of applications, namely "realtime applications" for which node.js would be suitable.
Again lets consider, traditional web apps, which require to show data that changes frequently at the backend. The traditional approach using Http is for browser based javascript clients to "poll" the server using "auto-refresh" tags. This approach apart from loading up the server is also very unoptimized, instead newer full-duplex protocols like websocket, can be used by the servers to push content, messages, notifications to the client browsers, "whenever" the server events occur.

This event driven approach, to pushing from server to client is very compatible with node.js async and non-blocking APIs, hence there is excellent support in node.js based modules like socket.io, for server push. This makes node.js very suitable for web applications that require high interactivity, server push and notifications.

What is node.js and how useful is it to build real life web apps from scratch?

Well node.js core is really a http server and a platform for hosting web apps. The core node.js hence does not include any features which directly are used in the making of a web application. To create a real life web application, one needs a framework with many features like ability to host static content from the server's native file system, user authentication, session and cookie management, templatable views, nagivation and routing framework, binding model and views, error handling, request body parsing etc.
For providing all above functionalities the core node.js needs to have relevant modules added on top of it
Node.js provides a robust module system called npm stands for Node package manager, which helps in installing such node.js modules.
The most critical module which provides pluggable middle-ware is a module called connect.
On top of connect is a module called express.js which provides a full fledged web application framework.
More custom requirements for the web app can be fulfilled by installing appropriate modules freely available via the npm (node package manager).
Similarly, templating engines like jade and ejs can be plugged into frameworks like express.js, thereby enriching the node.js ecosystem for your web application development.

In subsequent articles, I will be walking through developing a basic node.js web application for doing CRUD (create, read, update, delete) into a mongo database. You will be pleasantly surprised how easy and elegant it is to develop web applications in node.js based frameworks.

Cheers!


Posted by at 2 comments:
Labels: , , ,

Monday, March 10, 2014

How to build a cross platform mobile app using only a browser

Posted by at No comments:

Friday, February 7, 2014

Securing your REST API



With developers exposing application functionality as REST services, willy nilly all over the enterprise, the onus of securing these REST services is on them as well. Here I will discuss the options for means of authenticating your REST services. For authenticating REST services you have the following broad options:


  1. Use HTTP Basic Auth, Digest, Form based or Client Certificates
  2. Use custom token based authentication mechanisms
  3. Use OAuth 2.0 - Two legged or Three Legged Auth


Using HTTP Basic Auth, Digest, Form based or Client Certificates
Since HTTP is the most popular implementation of REST, Java EE based authentication mechanisms hold true for REST service calls as well. Here we have 3 options, as mentioned well in Java EE Security documentation.

To secure REST API exposed at http://<hostname>:<portnumber>/web-app-context/webapi/rest-resource we will use the following configuration in web application's web.xml




Above, configuration uses the "Basic Auth" scheme, similarly REST based (logical) resources, can be secured using DIGEST, Form Based and client-certificates schemes as well. Please refer Java EE security documentation for further details.

Also, suitable realm can be used to refer to credential stores. If you want to make the actual authentication to be portable across application servers you can use JAAS and write-up your own custom LoginModule and CallbackHandler.

So far so good, securing REST services is like any conventional Java EE web application. But....

Many times, the REST services are consumed by not conventional browser based UIs, but rather by mobile applications based on say android or iOS. In such cases, having a mobile app which needs a re-login after  HttpSession timeout of say 30 minutes(for tomcat), can be very tedious and undesirable. Instead most mobile apps allow user to enter the username and password, once and then store it on the mobile device as an app preference.

In order to provide a feature such as above, with mobile clients in mind, we can use "custom tokens with expirations". The idea itself is quite simple.

  1. The first time a mobile user uses the app, he is asked for a username and password for authentication. 
  2. This server backend provides a REST API such as /login which takes a Http POST and username and password as part of Http request body. 
  3. The password itself can be sent across using encoding such as base-64 (over SSL obviously!) 
  4. The server validates the username and password going against a credential store such as LDAP based or ActiveDirectory based. Once the user is authenticated, a unique token is generated by server, the server saves this token against the username, along with say a timestamp and expiry date time and also the token is sent back to the client.
  5. The client stores this token say in HTML5 localstorage and uses it in subsequent REST requests, in a custom http header
  6. For subsequent requests, the server looks at the custom header retrieves the token, validates that it is valid by checking against the username and also ascertaining that it has not expired as per expiry policy.
  7. If token is valid, the request goes through, if token is invalid or expired, the server throws back a 401 error, which makes the client go back to login page for re-login
The above mechanism is depicted in representative code below, to clarify the explanation.

The server side authentication and token check can be done using, a servlet filter interceptor as depicted below:

package com.mastek.opensource.security.filters;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class SecurityTokenFilter implements Filter {
 
 @Override
 public void doFilter(ServletRequest req, ServletResponse resp, 
   FilterChain chain) throws IOException, ServletException {
  
  HttpServletRequest request = (HttpServletRequest)req;
  String token = request.getHeader("MyTokenField");
  
  //additionally check if the token is valid
  //valid can also check if token is expired as per policy
  if(token == null || token.length() == 0)  
     //send HTTP resp code 401: Unauthorized
     ((HttpServletResponse)resp).setStatus(HttpServletResponse.SC_UNAUTHORIZED); 
  else
     chain.doFilter(req, resp);
  
 }


 @Override
 public void destroy() {

 }
 
 @Override
 public void init(FilterConfig arg0) throws ServletException {

 }
 
}
The servlet filter entry in web.xml is shown below:

The ajax request which sends out the token in custom Http header and redirects to login page if server throws a 401 is depicted below:


$(document).ready(function() {
$.ajax({
    type: 'GET',
    url: "my-url",
    dataType: 'json',
    data: "{ 'name': 'somedata'}",
    beforeSend: function (request){
        request.setRequestHeader("MyTokenField", localStorage.userToken);
    },
    success: function(mydata) {
        console.log('data ret='+JSON.stringify(mydata)) 
    },
    error: function(mydata){
        if(mydata.status === 401){
            alert('Redirecting you back to login page....');
            window.location = "login.html";
        }
    }
});
 
});
I have'nt put up the /login API, but its easy to imagine that, as a service which takes in username and password, and returns back a token.

The above mechanism is still suspectible to man-in-the-middle attacks, for which the transport needs to be secured with SSL, any which ways. Libraries for generating hash as the unique token are available in javascript as well as java.

The flexible thing about custom tokens, is that you can put in code on your server side to implement any particular policy for the token expiration. Example tokens can be to expire in a day or in a week. Also, keeping track of active users in your system is easier.

I will leave the OAuth 2.0 two-legged mechanism for a subsequent article, since this one is getting too lengthy as it is :-)

Hope you enjoyed the discussion above, related to basics of securing REST services.

Cheers!
Posted by at No comments:

Tuesday, February 4, 2014

Backbone.js - Getting Started Tutorial

When I started learning backbone.js, though there were several getting started tutorials, all of them seemed a little aggressive, since they introduced all the backbone features in a single, supposedly simple application. In this tutorial I am going to introduce each of backbone basic concepts incrementally and kind of provide a less steeper introduction to backbone.js for beginners.

Lets jump right in....

We will start out with a bare bones html file, which can be thought off, as the anchor or home page for the backbone application. Lets name it bb-intro.html.

Initial listing of bb-intro.html




Next we will create a "router" in backbone, it is like a navigator component, which maps URLs to views/templates.

Lets have 3 pages(views) in our application, to be able to display these on demand we will define the following routes.


 var AppRouter = Backbone.Router.extend({
   routes : {
    "" : "showPage1",
    "page1" : "showPage1",
    "page2" : "showPage2",
    "page3" : "showPage3"
   },
   showPage1 : function() {
    new AppViewPage1().render();
   },
   showPage2 : function() {
    new AppViewPage2().render();
   },
   showPage3 : function() {
    new AppViewPage3().render();
   }
});



  


var appRouter = new AppRouter();
Backbone.history.start();





The route entry "" implies the default html page and refers to the following URL

http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html

or

http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html#





The entry "page1" refers to the following URL:

http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html#page1



The entry "page2" refers to the following URL:

http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html#page2



and so on....I think you get the picture here :)





Next up, is the views like AppViewPage1, AppViewPage2, AppViewPage3, these are as you might have guessed javascript objects defined as follows:








 var AppViewPage1 = Backbone.View.extend({
  template : _.template($('#page1').html()),
  render : function() {
   $('#container').html(this.template());
  }
 });
  
  
 var AppViewPage2 = Backbone.View.extend({
  template : _.template($('#page2').html()),
  render : function() {
   $('#container').html(this.template());
  }
 });
  
 var AppViewPage3 = Backbone.View.extend({
  template : _.template($('#page3').html()),
  render : function() {
          $('#container').html(this.template());
  }
 });





The code for each AppViewPage is quite simple stereotypical, for illustration purposes.



We use the underscore library's api _.template( ) to load a template string

And in the view's render method, we simply assign html content of the div with id "container" using familiar jQuery syntax.



Next up is the definitions of the template themselves. These are html templates containing valid html elements.











Thats it!
When you access the above html in browser, it should show the following screens with proper navigation when clicked on the hyperlinks.



Notice that the hrefs in the templates, refer to relative URLs, with values like "#page1", "#page2" and "#page3". This is same as the values we specified in the mapping in our router definition.



















Now that we are comfortable with navigating between views, using backbone. Lets turn our attention to features called model and collection provided by backbone.



Lets jump right in by defining a model and collection and try to use the same in our view.






 MyModel = Backbone.Model.extend({
  defaults : {
   title : 'Default Title',
   status : 'Initiated at '+new Date(),
   attrib1 : 'Value1',
   attrib2 : 'Value2',
   attrib3 : 'Value3'
  }
});

 MyCollection = Backbone.Collection.extend({
  model : MyModel,
 });
 
 var myCollection = new MyCollection();
 myCollection.add(new MyModel({title:'Page1'}));
 myCollection.add(new MyModel({title:'Page2'}));
 myCollection.add(new MyModel({title:'Page3'}));
 myCollection.add(new MyModel());



The above code defines a MyModel and MyCollection.
We then instantiate a MyCollection object and add 4 MyModel objects with custom titles.



When the template is attached to the view, we need to additionally pass the collection as a template parameter.
This can be done as shown in the code below:


  
var AppViewPage1 = Backbone.View.extend({
template : _.template($('#page1').html()),
   render : function() {
 $('#container').html(this.template({mydata:myCollection.toJSON()}));
   }
});







The template itself needs to be tweaked to iterate over the collection and start displaying the passed data parameters.
This can be easily done as seen in the snippet below:







Apart from above mentioned features, the backbone model does provide the following important features:



Ability to listen to changes in model

In the model's initialize function, we can listen for changes to specific model attributes as follows:


initialize: function(){
            this.on("change:myattrib1", function(model){
                var newvalue = model.get("myattrib1");
                alert("Changed myattrib to " + newvalue );
            });
}






Interact transparently with a REST service back end

On the model we can invoke stock framework methods like save( ), destroy( ) and fetch( ), which result in HTTP methods PUT, POST, DELETE and GET, getting fired under the hood by the framework against a URL specified in the model's attribute called 'urlRoot'.



Thus there is no need to explicitly use jquery or ajax to make server side requests, the backbone.js model does it for you transparently.




    var UserModel = Backbone.Model.extend({
        urlRoot: '/user',
        defaults: {
            name: '',
            email: ''
        }
    });

    var user = new Usermodel();
    // Notice that we haven't set an `id`
    var userDetails = {
        name: 'Ganesh Ghag',
        email: 'ganeshghag@gmail.com'
    };

    // Because we have not set a `id` the server will call
    // issue a post  /user with a payload of userDetails data above
    // The server should save the data and return a response containing the new 'id'
    user.save(userDetails, {
        success: function (user) {
            alert(user.toJSON());
        }
   })







Support for Model data validation

There is a provision in the backbone model to provide standard callback to validate model data before submission to server and also to raise error( ) callback in case validation fails. This is depicted below:






// If you return a string from the validate function,
// Backbone will throw an error
validate: function( attributes ){
            if( attributes.age < 0 ){
                return "Negative values are not allowed";
            }
},
initialize: function(){
            this.bind("error", function(model, error){
                alert( error );
            });
}



So far we have been able to use backbone to display views, navigate between views and bind and show model data and collections, into the views.



Lastly to attach events to elements in our backbone views is as easy as specifying events attribute of Backbone.View as follows:






SearchView = Backbone.View.extend({

        events: {
            "click input[type=button]": "doBtnClick"
        },
        doBtnClick: function( event ){
            alert( "from inside search button click" );
        }
}

});





With this we have covered most basics about the the backbone framework. You should now be heading towards more advanced tutorials on backbone.



Cheers!











Posted by



at





3 comments:
  



























        

      









Subscribe to:
Posts (Atom)