iToto's Blog

A Montreal based full-stack web developer who loves learning and trying out new things. This blog is my attempt to document my work as well as a place to discuss ideas or topics that I find interesting. Feel free to follow me on linked social networks.

Filtering by Tag: nodejs

The Evolution of Web Applications

I have been developing web sites/apps for almost a decade now. The thing I love most about web development is that it's universal. The majority of web applications are supported on almost any platform. In a world where people are more openly using their platform of choice, this is a huge advantage. It ultimately allows us to have one code base that be executed on any platform. This is the general idea behind things like PhoneGap. All a web app needs to run is a decent and recent browser.

The Modern Web Application

Web applications have come a long way in recent years. In the beginning, applications only had interface with one client - the web client. This meant that developers only handling web requests that came from the views they developed (usually in the same framework). These days however, it's all about applications interfacing with other applications. And with the addition of mobile, web applications are more in demand as ever!

To adapt to this change, web applications are now broken up into two parts: an API and a Web Client. This modularization exposes a generic server-side application that can essentially communicate with any client-side application. I call this a service/client model. When I first started to develop with this model, I began to appreciate web applications a whole lot more. These days, if I'm making a web application, I try my best to fit the application in the service/client model.

The Move To JavaScript

Most of the web applications that I have written have been in PHP with frameworks like CakePHP, CodeIgniter and Laravel 4. The issue with these frameworks is that while the server-side scripting is all in PHP, the client-side scripting is done in JavaScript. This forces developers to either learn both languages, or leave the JS part to developers that are stronger in it (which is where the front-end/back-end developer division starts). I personally believe that any good web application developer should be able to work in both.

What would be great is if web applications used the same language throughout the stack. Well, if you're a JS developer, you're in luck!

With a server side application running on node.js and client-side applications running in frameworks such as backbone or angular you can now switch between back-end and front-end development without changing languages. Furthermore, if you use MongoDB as your data store, you can now have a full stack running on JS!

On top of that, node also introduced something else to web applications that wasn't really possible before (or at least not as easily achieved) Web Sockets! This allows for full duplex communication between the clients and server (no more polling!). Web sockets takes web applications to a whole new level. With it, it's now possible for clients to get updates in real time.

To further on this, I came across Meteor - which essentially is a web application platform that allows real-time communication between clients and the server. When I saw this, it furthered my belief that this is the future of web applications. The age of clients polling the web server for updates will soon be a thing of the past.

Another example of this is emberjs. Man, there are so many new JavaScript platforms it's a little overwhelming lol.

Further Reading

This blog post goes through the evolution of web applications as I tried to depict in this blog post.

Ready For Collaboration

Finally got around to setting up all the repositories on Github for Party Stream. There are several parts to the system and I'm really happy to say I have already received volunteers to work on some of them.

Here is a list of projects that are open for collaboration:

  • Web App
  • iOS App
  • Phonegap App
If you are interested in contributing to either of these projects, please send me an email with your Name, Github account name, Dropbox associated email and which project you want to work on. You will be invited to a shared Dropbox folder that will be used for the diagrams and artwork.


If you are working on any of these projects, there are some guidelines that I would like to follow:


First thing's first, please work off your forked copy of the repository. Do no work directly on the repository on my account. If you are new to Github, here is a introduction to Forking.

Git Flow

If you haven't been using a good workflow with git, may I introduce: Git flow, the only workflow you'll ever need to know about! I use this religiously as it helps keep source control simple and easy - especially for collaborations. I will be using this on each of the projects and I suggest you use it on your forks as well. It will keep it simple when it comes time to create your pull requests. If you use Source Tree it actually incorporates git flow – which is really helpful. They have both windows and mac versions.

Pull Requests

When you're done working on a feature and are ready to bring it to the main repository, please make your pull requests to the Develop branch. Nothing should ever be merged into the master branch as it is reserver for stable releases (see git flow).

That's it for now, I will add more as the project progresses. Thanks ahead of time for all those interested in the collaborations.

Happy Hacking :)


Once you're setup and ready to start contributing, we need to let everyone else know what you're working on. For this, we will use GitHub Issues.

If you see an issue that you'd like to work on, assign it to yourself. Otherwise, simply create an issue specifying what you are implementing and assign it to yourself.

Pushing for change: why the old way might not always be the best way.

If you’re looking to start a new application – let’s say a web app; you have one major decision to make before you start developing: what will your app be written in? 

There are many answers to this question, eg: PHP, Ruby on Rails, Backbone.js, Node.js, Pearl,  Java, ASP and many more. Each have their pros and cons, so ideally you’d like to chose the one that best suits your needs. I’m not going to go through each of the platforms because that would take forever. However, I will separate them into two general categories: Legacy and New-Age.

Legacy (PHP, Pearl, Java, ASP etc.)

These are the languages that have been around since the beginning of web development. They’re tried, tested and true. Most large companies tend to use them because they generally have tons of documentation or are very well supported. I’d like to think of these are the well rounded and safe solutions because they can do anything in a “good enough” manner.

New-Age (Rails, Backbone.js, Node.js, Closure etc.)

These are the languages that have been created as a result of the web application age. They aren’t as well documented or supported as their legacy counter-parts because they just haven’t been around long enough. They are generally used with companies that like to innovate and push the envelope by creating cutting-edge products. These platforms, however, are not as well rounded as the former solutions. These each have some flaws, however, what they do well, they do exceptionally well. 

I’ve been in both of these situations. I’ve seen the pros and cons for both sides and have had to deal with the development of both kinds of products. As a result, I have made some observations that I’d like to share:

Playing it safe is generally a good idea if you want to create something fast and use existing products. If you’re looking to release as fast as possible and don’t care about creating cutting-edge software, this is your best bet. A plethora of documentation is just a google query away and you can probably even find most of the code that you would need already done. Also, because most programmers post or release a lot of open-source code, you have years of R&D from others at your fingertips that will help you finish your product.

However, if you’re not scared to learn new technologies and are comfortable with finding new ways of doing old things then New-Age is the way to go. 

Personally, I lean towards the latter. The world we programmers live in is one that is always expanding and where we crave to use the latest and greatest technologies. These technologies wouldn’t get any better if no one used them. In-fact, the legacy platforms wouldn’t be where they are today if nobody used them and, as a result, improved them. Therefore, I like to use the newest stuff whenever possible. Obviously I’ll use the solution that best fits my needs, but if there is at least one viable solution in the New-Age pile, I’ll take it.

Quick update

Hey all. Just wanted to post a quick update on my progress.

After my last post, Amazon had announced that it has now supported Node.js with AWS. I was relieved to see that as I wasn't too thrilled about using a a library that may or may not be maintained in the short term. 

The GitHub project for the SDK is pretty good. I've been able to painlessly upload test files to my S3 storage from my application and have already begun creating my module. To all those that were looking to integrate AWS with their Node.js application, it's now a npm command away.

Aside from API development, I have decided to begin working on a front-end website that will give a preview of the app so that I can start announcing it to the world and see if there is any demand for it. As of now I'm going to be using Twitter's Bootstrap along with LaunchRock for the initial sign-ups for people who want to get into the beta when it is available in 2013. I will post the link to the website once it's ready, so keep an eye out.

Starting with Amazon AWS

So this weekend I started working with Amazon's AWS - more specifically, S3. I will be using S3 with my app as a file storage solution.

My experience with AWS thus far has been stellar. Their automated phone verification system blew my mind at how quick and seamless it was. It just feels like a high-quality service that's done right. As long as the experience continues like this, Amazon can have my money.

That being said, this experience furthers the notion of how important user experience is for a service/application. The better the user feels using your product, the easier it is for them to open their wallets to you. So, my main priority when developing the client application will be simplicity and ease-of-use. I believe that if an app is easy to use and clear to the user from the get-go, it will lead to an overall pleasant user experience.

My next step is to tie in the S3 storage with my Node.js API. Design wise, there are two ways for me to implement this. 

1- Client --> S3:

This method requires the client application to send the file directly to the Amazon S3 server.


  1. Less stress on API (bandwidth, processing, request handling, etc.)


  1. Any processing on the file must be done on the client side
  2. Meta-data still needs to be sent to the API for database entries
  3. Creation of unique identifiers are done from API, so this will result in more requests for a file upload.

2- Client --> API --> S3

This method requires the client application to send the file and all data to the API who then does processing and uploads the file to the Amazon S3 server.


  1. No processing needed on Client side
  2. API can do post processing on all files before they are uploaded to S3
  3. All meta-data can be stored simultaneously to the file upload, to ensure synchronization.


  1. More strenuous on the API (bandwidth, processing, request handling, etc.)


        For my application, I believe the second solution to be the best choice. I'm going to go with that for now and see how much stress the API will undergo with the file uploads. If it really is strenuous, I may be forced to switch to the first solution. Only time will tell.

        Also, for anyone else looking to use Amazon S3 with Node.js, I have found these repositories that you might find helpful: