All posts by Tomcy John

Tomcy John

About Tomcy John

He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently the Senior Technical Engineer at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Principal Architect to facilitate incorporating Spring as Corporate Standard in the organization.

Microservices – Full-fledged project using Spring Framework

As part of Microservices Hackathon (a technical hackathon), was fortunate enough to work with some like minded folks and with the help of an existing project in Github, was able to create and extend a full-fledged microservices based project using Spring Boot, Spring Cloud and obviously Netflix-OSS.

The project can be found in the below link location:

Let me know your comments on this.

Page Visitors: 259

History of Web Application

The Figure below clearly depicts the exact evolution of web application all the way from its humble beginning in early 90’s to the current state.

History of Web
Evolution of Web (Copyright Raytheon Company)

It’s very hard to clearly separate Web 1.0 from web 2.0 as there wasn’t anything different which got introduced in Web 2.0. That’s the reason the figure above clearly doesn’t put in a timeline as these are not very clearly defined. Having said that, it evident from the figure that, over the last few decades there has been substantial change in how we see web sites/ applications. When the web initially started, these were not called as applications; rather these were called as sites, with static content and hyperlinks which allows users to navigate from one content page to another. After that came the existence of CGI and Servlets which allowed these static sites to become dynamic and more personalized. These sites slowly started calling themselves as applications as they start to do some basic stuff which a client server application could do for a user. The scene of web applications quickly changed with the introduction of MVC frameworks (In the world of Java Struts was one of the initial MVC frameworks) and the templating engines. These changed the way we looked at web applications and there was a huge rise in people adopting it to make web applications for businesses. With the introduction of Web 2.0 standards, another important addition to the web came into existence in the form of AJAX, which helped web applications to render parts of its page rather than generating the whole page at once. This made web more rich, faster and importantly brought about good user experience. With web 2.0 came into existence new standards (HTML5, CSS3 etc.) and these completely changed this space and a new paradigm shift began to be thought through in the form on client side MVC frameworks.

Page Visitors: 153

Spring Book – Chapter 14 – Spring MVC and Spring Web Flow

Disclaimer: The chapter have been written with figures sourced from various on-line materials. I haven’t been bale to attribute these figures with source. Really apologize for this. In case anyone has any issues in me using the figures and content, please drop an email to me at I will make sure that the details are either attributed or the image/content removed from my blog post. Thanks in advance.

Spring Framework’s web application support is through two sub-projects namely Spring MVC and Spring Web Flow.

Spring Framework has its own MVC based web application framework in the form of Spring MVC. They conceived and developed its web framework to address some of the deficiencies and poor design consideration in other popular framework available in the market. One of the main deficiencies identified was the lack of separation of concerns like proper separation between the presentation and request handling layer and between request handling layer and the model layer. Similar to Struts, Spring MVC is a request-based web application framework. Spring MVC makes sure that all the interfaces are tightly coupled with the core Servlet API’s rather than the Spring API’s.

Spring Web Flow is one of the sub-project which aims at providing the infrastructure for developing and running web application. It tries to aid web application developers in defining appropriate navigation rules, manage navigation and conversational state as well as facilitating high level reuse and modularization.

Spring MVC as well as Spring Web Flow is a very huge topic to cover in one Chapter. There are books written only on these topics. I would cover some basic concepts of both Spring MVC and Spring Web Flow in this Chapter. The first part of this Chapter makes you walk through Spring MVC and the second part of this Chapter walks through Spring Web Flow. I will try to cover basic detail of both frameworks so that you will get a heads up on these and can start off developing using these.

Spring MVC

Spring MVC allows you to build extensible, robust and loosely coupled MVC-based web application. With the use of the famous Model-View-Controller pattern, it inherently brings separation of the various layers in a typical web application namely business, presentation and navigation in a clear way.

We have covered MVC pattern in detail in this book, but just to refresh your mind, the responsibility of Model is to encapsulate the application data, the responsibility of View is to render the response to the user with the help from the Model object and the responsibility of Controller is to receive the request from the end user and transfer it to the back-end services which will populate the Model objects and sends the view object to the user.

Spring MVC's fit in an enterprise application containing other layers

Figure 14-1. Spring MVC’s fit in an enterprise application containing other layers

Page Visitors: 3625

JavaScript Database Library – Part 2

Earlier I wrote a post in which I tried to cover as much libraries as possible in the space of “JavaScript Database Library”. Later on I realized that that was in no way a complete list. When I research more, I could see another set of libraries as detailed below, which falls into the same category. Still I am not claiming that the list is exhaustive, but at least it gives various options we have in hand before selecting one for your application development.

Missed ones:
1. story.js –
2. persistence.js
3. persistJS
5. localStorageDB
6. realStorage
7. YUI3 CacheOffline
8. DomSQL
9. Impel
10. ActiveJSActiveRecord
11. JazzRecord
13. ShinyCar
14. lscache
15. microcache.js

One day I hope to write at least a small abstract on each one of these and also create some matrices which can be used meaningfully to select a particular library for your application.

Page Visitors: 74

JavaScript Database Library – Part 1

JavaScript is a universal language now. Its popularity, usage and its capabilities will keep increasing day by day. The future of especially web application development is in the hands of JavaScript and its various libraries and frameworks.

With node.js, JavaScript has also captured the niche server side as well in storm. In distant future, just by knowing JavaScript you would be bale to code an entire web application, both server and client side with ease.
This post, i cannot call as a very good blog post, but i just wanted to share the list of JavaScript database libraries i just searched using Google. Some of them might not be that useful a library as of now but can go on become more mature down the line.

The below lists some of the JavaScript database library:

TaffyDB –
Lawnchair –
Storjsdb –
Jstorage –
SQLite –
PouchDB –
Loki.js –
Store.js –
Sql.js –
BankersBox –
IDBWrapper –
JayData –
Kizzy –
Artemia –
Strg.js –
localForage –
Rhaboo –

The above list was gathered from mere Googling and by reading through below sites:

These sites lists most of the JavaScript libraries which exists around the world written by awesome people.

Now the big question, which one should i use or standardize as the best one to develop a medium web application?
I don’t know, if anyone can help me, please drop me a comment and i will try to collate it and put another post, which would be more relevant and meaningful a post fr others.

Page Visitors: 160

Web Application Development Guidelines

Disclaimer: The content in this blog is plagiarized from various sites and blogs and is considered as a place where all their views are consolidated and put into a view which can be used as a guideline for any web application development. All the articles from which this blog is based is given below in the “Reference” section. Thanks for all the great authors and their work. Truly Appreciate!


This document aims at providing a basic guideline using which UI/UX  team can develop the web application story board. Mobile optimized web application is gaining traction and it’s time for any web application being developed to consider mobile devices. On a high level mobile optimized sites can be built using the below:

  • Responsive Web  Design (RWD) – The document does give more insights and details on this design as this most talked design consideration in regards to web application.
  • Having different set of HTML and CSS catering to desktop and mobile device served by detecting the user agent and a single URL. Not considered to be a real way forward because of alternates (RWD).
  • Two set of URL for desktop and mobile and is decided agent sniffing the user agent. Again, not considered as a choice because of alternates available and cons attached to it is high as opposed to pros.

Design Principles

Some of the design principle which needs to be kept in mind is:

  • Responsive Web Design
  • Mobile-first design
  • Progressive enhancement and gracefully degradation

Responsive Web Design


Figure 1 Responsive Web Design

Ethan Marcotte coined the term responsive web design (RWD) in the year 2010. Responsive web design is a setup where the server always sends the same HTML code to all devices and CSS is used to alter the rendering of the page on the device using media queries. In essence responsive web applications respond to their environment. It’s considered as a cost effective way to mobile application. RWD is achieved using the following:

  • Fluid/flexible grid-based layout
  • Fluid images and media
  • Media queries and media query listeners

Having said that we can indeed have a mixed approach where we have a fixed width for large and medium screen widths and fluid widths for small ones. Whether small, medium or large, one site for every screen out there is the ultimate aim which RWD brings onto the table.

Why Use?

  • Day by day number of devices, platforms and browsers are increasing and your application should be able to support as much as possible without breaking and without compromising user experience.
  • A single URL for a piece of content makes it easier for your users to interact with, share, and link to your content
  • No redirection is needed for users to get to the device-optimized view, which reduces loading time. Also, user agent-based redirection is error-prone and can degrade your site’s user experience

When to use?

  • Time & Money
  • Browser support
  • Performance
  • Content
  • Website Vs. Web App


If you go for framework, it will definitely save time. Otherwise, we can go in-house, to have more control but we might be stuck where we are if there is no roadmap. There are good amount of frameworks, well tested and established which can be used:

  • Twitter Bootstrap
  • The Goldilocks Approach (
  • Foundation
  • Skeleton etc.

At an onset, Twitter Bootstrap is the most promising one and once we do a full on paper evaluation to arrive at a choice.

Mobile-first Design

Historically, most web designers and their clients have approached the desktop side of any project first, while leaving the mobile part as a secondary goal that gets accomplished later. There’s a growing trend in the industry though to flip this workflow on its head and actually begin with mobile considerations and then work up to a larger desktop version. Mobile-First Responsive Web Design is a combination of philosophies/strategies, and ultimately boils down to a broader application of good old web best practices. As the digital landscape gets increasingly complex, we need to design experiences that work across the entire spectrum of digital devices.Mobile First is a philosophy created by Luke Wroblewski and as detailed above highlights the need to prioritize the mobile context when creating user experiences.


  • Mobile isn’t a trend, nor is it even the future, it’s the present.

o   Almost 25% of the Web’s traffic now comes from mobile. If you didn’t build a responsive site, you’re already losing a quarter of your users.

o   Mobile device sales are increasing across the board with over 85 percent of new handsets able to access the mobile Web

o   Mobile device sales are increasing across the board with over 85 percent of new handsets able to access the mobile Web

  • There are good amount of tools, technologies and framework available which will let you do this design principle easily.
  • Announcement from Eric Schmidt in 2010 that Google was going to be taking this approach from now on. No problem going behind great leaders in this space.

When to use?

All the points as discussed in RWD holds good. It does put some constraints and pressure on the developer but its worth in long run and above all good for business.

Progressive Enhancement and Graceful Degradation

Mobile-first responsive web design comes down to using Progressive Enhancement and Graceful Degradation as a foundation for web strategy and design. Designing with progressive enhancement involves smartly adding layers of enhancements to a strong foundation in order to deliver an accessible and optimized experience to all. Starting with mobile and designing with progressive enhancement covers all bases (even if just at a rudimentary level).

Progressive Enhancement and Graceful Degradation


Figure 2 Progressive Enhancement and Graceful Degradation

Note: Don’t misunderstand visualizing the above figure as almost equal to the RWD figure. Not only will the form factor changes when being used across multiple devices, the capabilities of browsers rendering these pages also have different capabilities.

How an application should be conceived and designed to achieve this design principle


Figure 3 How an application should be conceived and designed to achieve this design principle

Figure 3 above depicts as to how to code your web application and what are the languages to be used and for achieving what. The content should be taken care using HTML (HTML 5), all styles and presentation around the content should be handled completely using the CSS (CSS 3) and behaviour should be achieved using JavaScript.

How the code should be structured to achieve this  design principle

Figure 4 How the code should be structured to achieve this  design principle

Figure 4 above explains Figure 3 in technical aspect clearly. You need to have a base HTML along with base CSS and JS which renders just fine in any browser (old ones). You need to have next set of nice CSS and JS which will adds more styles and behavior to the base one which works just fine in medium range browsers (IE 6, IE 8 etc.). You need to have awesome CSS and JS adding on top of base and nice CSS and JS, which will run just fine on all modern browsers (Chrome, Firefox etc.).


  • If this design principle is not given due respect, developer may limit the websites functionality considering it work fine in older browsers
  • Sites break when rendered with older browsers


  • Use HTML 5 and CSS 3 and make sure that the code is W3C compliant
  • Consider above design principles in all aspects (guideline as to when each should be considered is detailed in the following section)
  • Use detection libraries like Modernizr ( to eliminate or rather adapt your web application to various HTML5 and CSS 3 capabilities each browser supports.


Any web application being developed can be categorized broadly into different categories. One such category is:

  • Internet based (staff as well as external customer accessing web applications)
  • Intranet based (exclusive for staff)

Another way of categorizing a web application broadly is as below:

  • Web application having a definite mobile strategy

o   Maintaining a mobile only site and based on the user agent detection call appropriate URL’s

o   Having a native application specifically developed to cater to the mobile devices

  • Web application not having a definite mobile strategy

o   Most of the intranet staff application fall into this category (this is something which has been done in the past but with the growing tendency of staff asking for application to be accessed using a mobile device is growing)

For internet based web application having a definite mobile strategy, making the web application align with these design principles should be looked upon on a case to case matter as there is a cost involved in making a web application align with these design principles. Since there is a mobile strategy already existing for this web application, users does have an alternate way of accessing the application wither using a dedicated mobile URL or using a native app. Having said that, both mobile web URL and native app does have some dependency on the device being used and ideally considering the cost, going with our design principles and considerations as detailed above is encouraged. For internet based web application not having a definite mobile strategy, the application should be built using all the design principles and considerations as detailed above. The reason being, the application can be used by users in different parts of the world using different devices and browsers and the application should be ready to support this diversity. For intranet based web application having a definite mobile strategy, to not overburden the budget the design principles can be compromised but considerations should be taken into account and implemented. Ideally, if the application is responsive in nature even the mobile strategy of either having a dedicated URL for mobile or a native app can be reconsidered and can be taken out of service and replaced with the responsive site. For intranet based web application not having a definite mobile strategy, according to the usage patterns (analytics gathered from existing application or forecast and prediction on usage of mobile devices) the decision on whether to go with design principles has to be made. But, the considerations have to be taken into consideration and implemented. Note: Optimizing for every web-enabled device on earth is impossible, so eventually you need to make the strategic decision of what target devices and browsers for which the web application needs to be optimized. This decision can be based on existing applications analytics per market research on target web applications user base.


  • Users care for content
  • Users use only one browser
  • Give incentives for users to upgrade to a modern browser
  • Support best possible experience (based on device and browser capabilities), not the same experience for all users
  • Do your presentation/styling using only CSS (CSS 3) rather than using tools or manual coding
  • Don’t try to make older browsers to do things they are never meant to do. If you do, you will have long development time, too many bugs and it will perform badly (slow pages).
  • Set of Html’s and CSS (the URL remaining the same) catering to whether the user agent is desktop or a mobile device seems too much maintenance havoc and should be avoided and replaced with RWD.


Page Visitors: 573