codeigniter-boilerplatejs

I’ve been thinking about using Codeigniter as the back end for a couple of single page applications where the front end would be implemented using BoilerplateJS architecture. I wanted to create the basic structure for such a project and share it. Today I came across this question and thought I’d do this project and share it. Surprisingly putting together BoilerplateJS and Codeigniter was a breeze.

Most of the BoilerplateJS code will reside in a public folder in the Codeigniter root folder. The index page of BoilerplateJS will be in views folder and will be loaded by a controller when necessary. After some path modifications in the BoilerplateJS index file and requirejs route configs, everything started to work perfectly. All the server calls that were simulated by JSON text files are now actually served from a Codeigniter controller. I also used CodeIgniter Rest Server to implement the REST API.

The project is at: https://github.com/slayerjay/codeigniter-boilerplatejs

As I mentioned in an earlier post, Single Paged Applications provide several advantages to the user. They provide a smooth and fast user experience.

Having worked in a large scale single paged application development project and co-authoring BoilerplateJS, I’ve realized Single Page Applications are easy to de-couple and modularize. For me, development wise, it is very easy to manage Single Paged Applications.

You may start your desktop application or web application with a clean code base, with a nice modularized architecture with a good separation of concerns. But I have seen many applications where the code starts to get messy as the development progresses. Given you have the right tools and follow good practices, a Single Paged Application is best type of application for a clean and maintainable code base.

Unlike traditional web applications, the presentation logic and the main logic of the application are highly de-coupled.

On a Single Page Application, the server-side will be responsible for:

  • Handling CRUD (Create, Read, Update and Delete) operations
  • Executing different operations and workflows (these may include changing states of entities, updating database records)
  • Authentication and Authorization (this should always be done on the server side to ensure that the requests are legitimate)
  • Validation of web requests
  • Providing an interface for the client application to perform operations (typically done via a REST API)

With the help of proper frameworks the above tasks can be handled easily on the server side. Entities that are related could be treated as modules. Aspect Oriented Programming techniques can be used for authorization.

The client side will be responsible for:

  • Populating and rendering the UI with proper data
  • Access the server via AJAX
  • Perform client side routing
  • Perform client side validation

If a proper REST API is defined, back end developers and front end developers can work simultaneously on the project easily. And since the front end and the back end are de-coupled by the REST API it is easy to change these layers without significant modifications.  Scaling up the back end or providing a new interface can be done with minimal impact.

This kind of separation where the server is treated as a service provider and the presentation logic purely done on the client side with JavaScript, makes the application design very straightforward and clean.

I am still an undergraduate, but I was involved in developing several applications, as projects and course work in the university and as products for several clients while I’m in the university and during my internship. I have seen that more and more enterprise applications are moving towards the web and have seen a trend towards enterprise applications being developed as Single Paged Applications.

Me, being an undergraduate is far from being an experienced software architect, but I have experience in developing the above types of applications, so here is my take on them.

Desktop applications may be connected through the internet or an intranet, and there may be server software or a database server in a central location. We have been used to these types of applications for a long time. They are reliable and very stable. But things have got complicated lately. There are a couple of popular operating systems, and most enterprises want their systems to be accessed by all such operating systems and devices as well. Developing separate native applications for different platforms is extremely costly and impractical. I believe that this is a major reason behind web applications being popular among enterprise application developers.

Web applications reside in a web server and accessed by users via the internet or an intranet and viewed on a web browser. Web applications provide some significant advantages. As mentioned above being platform independent is one of them. Unlike desktop applications they do not need special roll out or deployment procedures. Therefore deploying updates and new versions are very easy. The load on client machines is pretty low as well.

However there are several drawbacks of web applications. The user experience tend to be discontinuous because the pages need to refreshed each time an operation occurs, and response time is very slow because the webpage needs to be sent from the server. An un-interrupted connection to the server (or the internet) is required as well. But this however is minimized with HTML5’s new local storage feature.

Single Paged Applications tries to eliminate some of the drawbacks of traditional web applications.

A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.

In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or partial changes are performed loading new code on demand from the web server, usually driven by user actions. The page does not automatically reload during user interaction with the application, nor does control transfer to another page. Updates to the displayed page may or may not involve interaction with a server.

– Wikipedia article on Single Paged Applications

The following figure shows the architecture of a typical SPA:

Typical Single Paged Application Architecture

Since most of the UI rendering and manipulation happens on the browser it gives the user an uninterrupted experience, and since the load on server side is minimum, these applications tend to be very scalable. The Single Paged Applications tend to have a lot more modularized maintainable code, since the presentation layer is decoupled from the business logic and controllers. However Single Paged Applications have a long way to go and the technology is still maturing. But my bet is that we will see more and such applications in the future.