You may have already heard of this new thing called NodeRun, but if not, you really should check it out.  If you do any web or Node development, this site is for you.  No need to install anything on your machine, you just need a web browser.

Just a few benefits of NodeRun:

  • Free
  • Hosted in the cloud
  • Nothing to download or install because it has its own IDE and everything runs in the cloud
  • Comes free with its own database (MariaDb)
  • Node.js already installed and running

As far as how you can use NodeRun, there are far too many ideas to talk about in a single blog post!  So, I decided to share my experience with a tiny part of what it can do: REST Web Services.

** Important Note: Whenever working with web services you will need a tool to send all types of http methods.  Browsers support GET’s type out-of-the-box through the address, but browsers do not support PUTs, DELETEs, etc.  There are many tools that can do this (I personally use Fiddler), but for this blog post I have chosen to use a Chrome add-on called Advanced REST Client (ARC) because it is small and simple to install.

Using the REST Web Template in NodeRun

To get started, I created a New Space and chose the “REST Web Services” template in the Designer.  This template already has a couple Web Service examples built in, as well as a database with tables and data.  I published this Space just to be sure this template was in good working order. By launching the application, it opened a new browser tab with the heading of “Web Services Test”.

web services template on NodeRun.com
  • See the NodeRun documentation section about “Setting your Start File” to see how it knew which file was your application start.
  • I ran the space and followed the code through to find:
    • When launching the App – it goes to the “App Start File” – which is the test.js file.
      • I knew this because that .js file had a special looking icon that looks like the play button.
      • This test.js is actually a server-side program being run by Node.js.
    • Within that program it uses the display “test.json” which has a button labeled “Retrieve Customer List.”
      • When the test.js program hits certain functions it causes a response to go back to the client side.
        • In this case line 10 à display.testSceeen.execute();
        • This execute() function sends the response back to the browser with screen information to be rendered, and the Node.js server is “sort of”  waiting here for the user to do some action with that screen.
      • The very next line is the test.js. If getListButton is true it calls a function named getList, which shows us how to make a web service call to get a list of customers.
      • This test.js program shows me how to do server-side web service call:
        • /list
    • When the user clicks that “Retrieve Customer List” button it issues a request (with variable “getListButton = true”) to the server that will execute every next line of code within that test.js program.
      • After looking some more at the test.js code, I found that when you select a record in the grid, it also makes another web service call to get the details of a single customer:
        • /getCustomer/123
  • Because these web services are local services, we can go and see the code within them.
  • Because there were only a couple services, I could guess which JavaScript file went to which service, but a nice feature request could be a way to show which file goes with which urls.
    • I right clicked and chose properties on the list.js file because I thought this was the /list route.
File properties with NodeRun
  • What this is telling me is:
    • Express Route à This is a web service Using Node.js Express Routing
    • App Start Route à It is not the initial application route
    • HTTP Methods – This service is available to any of the HTTP methods
    • Route Path – The url to use to call this JavaScript module
      • So yes /list goes to the list.js
    • I then looked at the code within list.js to see super simple and easy to read code.
  • Then I looked at the other file (getCustomer.js), and again I found nice, neat and easy to read code.
  • I looked at its File Properties and it was a little different because this one contained a parameter in the Route Path.
files properties within NodeRun with 'customerNumber' highlighed in the route path

**Important to note à Notice the ‘:’ in the route path. This colon tells Node.js express that customerNumber will be a parameter and it should pass the value onto the program within the request.params object.

So, now that I have seen that the REST services are just .js files that are integrated with express routing via the file properties dialog, I wanted to see how I could call these same web services using something other than that test.js file.

  • I went back to the file properties dialog of the list.js file and copied that entire Route Path: https://noderun.com/run/scotroach/rest-web-services/list
  • I started the chrome addon [Advanced REST Client (ARC)], chose GET in the Method field, entered in that entire list.js Route path in the Request URL field, and clicked the Send Button.  Tada! It returned a Status 200 (OK) along with 122 customers in json format.
  • Then I changed the Request URL field from /list to /getCustomer/112 (so that it matched up to the getCustomer.js Route path) and pressed Send.  And walah, it too returned a Status 200 (OK) along with a json object with a single record containing the details about customer 112.

To get more familiar with Express and how all of this routing stuff works, check out their Routing documentation and their API reference documentation regarding Request and Response objects.  Those are the parameters being passed into these web services.

We have just scratched the surface of what can be leveraged by using web services.  What we covered in this example only uses one database table.  Imagine doing a process that involves several database operations and that is wrapped up into one single restful web service. Or maybe you want to build web services that wrap up your integrated third-party web services.  Now your client-side code can call your web services, thus making it less complex.

In a follow-up blog, I will take you on the journey of creating RESTful web services from scratch.