Buying the “dead-tree version” of this book will also get you access to the various electronic editions, so you can stock this beautifully typeset and layout book in your library and still have access to its content while at work (Manning also tend to ship very fast, up till now all my orders have been fulfilled and delivered to my home within 5 business days, from the US to continental Europe). Alas, that is enough praise for now, but it is well-deserved. Another resource that I have found quite useful in my learning of NodeJS and Express, is FreeCodeCamp: this site offers various “free” certification tracks, like a Front End Development Certification, Back End Development Certification and some more. Although I put free inside quotation marks, it really is free. However, you are kindly requested to make a donation to help keep the servers running (and why wouldn’t you?).
In this blog I am describing how I created a very simple WebAPI as part of a Free Code Camp trail, using cloud based tools.
Debugging is a walk in the park with Visual Studio Code:
Taking a different turn
Although I liked the Microsoft Visual Studio Code very much, following the trail set out during the initial stages of the FreeCodeCamp uncovered another jewel: Cloud9! Up until now, I had never imagined that developing in the cloud could be so easy and responsive. Cloud9 supports many different languages and frameworks and offers an entire development environment in the Cloud; together with cloud hosting your hobby applications at Heroku, this is an unbeatable combination in terms of ease of use and startup costs for the hobbyist developer.
First task: signing up for Cloud9 and creating a workspace. Signing up for Cloud9 is as simple as you could imagine. It does require your Credit Card Information, but they do have a free plan so getting started should not have to cost you anything. As I have registered myself for Cloud9 using my (two-factor authenticated) Github account, I do have automatic access to my repositories on Github. After signing up with c9 and creating a Github repository to store the code, creating a workspace connected to your Github repo just requires a few clicks:
After clicking the create workspace button, this will take under a minute to complete and have you coding your app in the cloud from your browser! Zero-install. Every (free) workspace comes with a single CPU, 512 MB RAM en a 2 GB disk (yeah, I am old enough to remember the times where people did – or did not – say that 640 KB ought to be enough for anybody):
As you can see from the above screenshot, the Cloud9 Web IDE does not only give you access to the IDE itself, but also gives you access to the underlying Ubuntu 14.04 OS, including permissions to install (as I did with the heroku CLI, formerly called the heroku toolbelt above). This article on Heroku explains in more detail how to get your command-line access to heroku up and running. After finishinf the app on your Cloud9 workspace, where you can also run/test/debug it until it satisfies your needs, deploying it to the Heroku Cloud Platform, where you make your new killer-app available to the world, is child’s play:
First, you log into your Heroku account by providing your access credentials from a terminal session using heroku login (I am using two-factor authentication for my accounts whenever possible, using the Google Authenticator as the second factor):
Next, create an application on Heroku as well; this can also be easily done using the Heroku CLI:
Next task up: associating my local Git repository on Cloud9 with Heroku: in order to deploy my application to Heroku, I need to setup a git remote for it, i.e. on my Cloud9 IDE I need to define a remote repository (aptly aliases “heroku”, pointing to the Git repository associated with my application on the Heroku platform). The Heroku Git repository’s address has been returned in the step above where the app on Heroku was created:
For Heroku, a Procfile in the root of your application file structure is required to instruct the platform what should be run for your application; in this case, a simple Web API, all that is required is the webserver:
Pushing the repo (changes) to the Heroku remote should be the trigger to rebuilt/-assemble/-start the application at Heroku:
After pushing the application to Heroku, it should be up and running for me to access it through the browser:
Apparently, there is something wrong here. Instead of a running application, I have been redirected to some generic Heroku error display. Fortunately, the Heroku CLI has a convenient command to examine the logs remotely from your development environment:
It seems that my application failed to bind the offered PORT and hence is stopped … I made a configuration error in which I have hard-coded the port I was listening on to be 8080, instead of binding this to the PORT environment variable as required by the Heroku platform. A simple fix:
After committing the configuration change and pushing this to both Github and Heroku for renewed deployment, the logs show a successful start this time:
As you can see, in this case Heroku has assigned port 44819 to my application and the platform does some port juggling to route the default HTTPS port (443) on fcc-timestamp-mn.herokuapp.com to the internal port (44819) it is listening on. Accessing the application with an date string returns the two date representations as a JSON object:
Now the application is running smoothly, returning the natural date and the “UNIX” date (although this is ‘just’ the number of seconds since the epoch instead of the number of milliseconds). And in case you’re wondering, it also converts the other way around ….
In my (very limited experience), Node.js combined with Express is a very good and easy-to-learn combination for building HTTP-based microservices. Combining them with Cloud9 and Heroku seems like a match made in heaven, easing the pain out of development and deployment by moving the infrastructure into the cloud so you can focus on development instead of ops-work!