Some time ago, while working on a proof of concept using an Oracle API product, I got exposed to server-side JavaScript programming. Or more accurately, programming Web APIs using the Node.js platform and the Express Framework (possibly I will elaborate on this experience later, after this product has been publicly released).

Over the last year, I have still had this nagging feeling of needing to look into this “microservices” thing and running it in some cloud environment. I have been scribbling in Python as well for the last year or so, but I could never be bothered too much into finding a framework for writing these backend APIs. However, in JavaScript this was just so easy to get started. If I can recommend one single resource for getting your head around Express, this would be Evan Hahn’s “Express in Action” published by Manning:

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.

Getting Started

Usually, getting started in some new development environment of platform, makes me reach for Virtual Box, install some flavour of Linux (usually Ubuntu, but as my professional environment is Oracle, this could also be Oracle Enterprise Linux) and install the required platform/tooling inside the VM so as not to litter my laptop with all kinds of experimental stuff. For my journey into the JavaScripting world, I started out much the same way and even more to my surprise, I found myself installing a Microsoft IDE inside my Ubuntu Linux machine, Microsoft Visual Studio Code. And I must say that I am really pleasantly surprised by its rich feature set and ease of use, very useful to a novice JavaScript Developer: Git integration, Code Completion, Syntax Checking, Debugging functionality … it is all there out of the box and there are also tons of useful extensions that can be easily installed. Instead of dabbling with ViM of Sublime and get the right set of extensions, just pull out Microsoft Visual Studio Code and start hacking! Well done, Microsoft.

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 ….

Conclusion

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!