I'm back again, sorry for the lack of posts. I worked very hard at university and the downtime I did have I spent playing games and going out! The student life will soon be over for me, I should make the most of it right?

My new blog series - Dissertation

This series of blog posts, tagged with Dissertation will all be about my dissertation! Who'd have thought!?

Like the blog posts of my Industrial Year, this series will act as a journal for my progress. I'm aiming to publish one post a week and I've got a tight schedule that I'll probably share in the next post.

What is my project?

You may recognise this logo, it's from a Hackathon project while at IBM! For my dissertation I'll be recreating the project as a software engineer, that means it'll be built properly and not hacked together under time pressures!

As a brief overview, the project aims to give people an easy way to find things to do in a given location and plot a route for you to do all these things it's found; An itinerary generator!

I'll be developing the project using the eXtreme Programming (XP) for one person, this means that I'll do a little planning each week before starting work for the iteration.

Each blog post will explain the tasks set for the iteration and my progress in the tasks. So now we're onto the main part of this post.

This weeks task

This week (or according to my Gantt chart, next week) my task is to investigate server configurations, with regards to Node.js. I am planning on using Node.js as the back-end of my application for a few reasons, such as:

• JavaScript for the fullstack, no added layers like you would have with PHP running on Apache or Nginx.
• The application is not CPU-intensive and can do without the overhead that comes with something like Ruby on Rails.
• NPM (Node Package Manager) is fantastic, it's like Gems for Ruby but they're installed locally not globally.
• Asynchronous requests, WebSockets make this possible for other languages but it takes a little more effort.

Why not Ruby (on Rails)?

One of the big positives about Ruby is that you can run database migrations with little effort. However this is pointless because my project is not going to use a database yet and even if it did, it would be trivial. Nothing that would require me to use migrations more than a few times for non-complex schemas.

A double-edged sword is that the Ruby on Rails framework is opinionated. This is great when you want to follow the grain of the framework, this is why Ruby on Rails is used for large teams or projects that can be handed off. It's easy to understand from a newcomers perspective. What if you want to do something unusual? You'll likely spend a lot of time fighting the Rails framework and figuring out how it would like you to implement the solution rather than actually doing it!

Performance-wise Ruby on Rails is slower than Node.js by no small margin, especially for a back-end as succinct as what I'm planning. Adding the Rails framework to my back-end will only encumber it.

Why not PHP?

The biggest issue I have with using PHP for this project is the fact that a PHP application is instantiated every time a connection it made. It is also slower than Node, like Ruby on Rails (Node is really fast). Node.js has better separation of concern than PHP, I'm sure we're all guilty of embedding PHP in our HTML and telling ourselves that it's okay.

Why use Node.js?

Node.js breaks tradition for many web-serving techniques, usually a new connection spawns a new thread which in turn boots-up the application. Node.js operates on a single thread, using non-blocking I/O calls to optimise the throughput and scalability. This means that it can support many more concurrent connections than the traditional technique, where each thread takes up a little more RAM on the server and will eventually max-out the available resources.

Image source - Toptal blog

Node.js can theoretically handle over a million concurrent connections, which is a lot of users, right?

The real worry with the single-thread approach is that heavy computation on the server-side can block the thread, with my application that isn't a worry. It's computationally inexpensive and is more focused on being able to have lots of users at any given time.

A big issue with Node.js is the fact that an uncaught error will stop the application dead in it's tracks. Uncaught errors cause the application to terminate. This can be solved by using an npm module like Forever, which would restart the application whenever it stopped running.

Node.js offers speed and a nonblocking I/O API. Node.js was created because concurrency is difficult in many server-side programming languages, and often leads to poor performance. Node.js provides an event-driven architecture and a nonblocking I/O API that optimizes an application's throughput and scalability. Developers write simple code and Node.js takes over. Node.js uses an event loop, instead of processes or threads, to scale. Callbacks are defined, and the server automatically enters the event loop at the end of the callback definition. Node.js exits the event loop when there are no further callbacks to be performed.

So this is my cursory investigation into my server configuration, so far it looks like Node.js is the winner.. We can see what I decided to go with next week!