Unlocking the Asynchronous Powers of JavaScript

When I got started working with Node.js and Express, one of the first things I had to really wrap my head around was JavaScript callbacks. This is a powerful functionality built into the language that allows you to defer action until a desired event occurs, while proceeding on with other activities.

The truth is, I’ve been using callbacks for a long time, I just didn’t really realize it. I work with jQuery constantly, and it’s designed with callbacks in mind, passing anonymous functions via its built-in methods to be triggered when certain events occur, for example. Still, I wanted to move beyond “I know this works” to “I know how this works” both with jQuery and JavaScript, so I dug out my copy of JavaScript: The Good Parts, did some reading, hit the web, did some more reading, and then wrote a few simple experiments.

I thought I’d write up a little tutorial to help folks who are new to the concept get started. Hope it’s useful!

I spent most of my (little) career until now building web applications using the MVC pattern with action-based (Spring MVC, Struts2, Servelt/JSP) and component-based (Tapestry, JSF) Java technologies. It has always been a classical model where the client requests a server that responds with a HTML page. Of course, I have built ajax powered web apps but I never got the chance to develop a real time single page application with a modern Javascript framework like Angular, Backbone or Ember.

So I decided to give it a try by building ChessHub.io with a completely new technology stack and way of thinking:

• Moving form Java to Javascript
• Moving from SQL to NoSQL
• Moving from multi-threaded Java servers to the single threaded NodeJS
• Moving from classic MVC + Ajax to real time with ExpressJS and Socket IO
• Moving from synchronous processing to an asynchronous model

If you want to quickly test your REST api from the command line, you can use curl. In this post I will present how to execute GET, POST, PUT, HEAD, DELETE HTTP Requests against a REST API. For the purpose of this blog post I will be using the REST api that supports www.bookmarks.dev. The API is documented with OpenAPI and available for testing in the browser at https://www.bookmarks.dev/api/docs/.

Basic time notions

Most web applications have to support different time-zones and properly handling time-zones is no way easy. To make matters worse, you have to make sure that timestamps are consistent across various programming languages (e.g. JavaScript on the front-end, Java in the middleware and MongoDB as the data repository). This post aims to explain the basic notions of absolute and relative time.

There may be cases when your REST api provides responses that are very long, and we all know how important transfer speed and bandwidth still are on mobile devices/networks. I think this is the first performance optimization point one needs to address, when developing REST apis that support mobile apps. Guess what? Because responses are text, we can compress them. And with today’s power of smartphones and tablets uncompressing them on the client side should not be a big deal… So in this post I will present how you can SELECTIVELY compress your REST API responses, if you’ve built it in Java with Jersey, which is  the JAX-RS Reference Implementation (and more)…