Lessons learned from building ChessHub.io

Codever Logo

(P) Codever is an open source bookmarks and snippets manager for developers & co. See our How To guides to help you get started. Public bookmarks repos on Github ⭐🙏

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

That was a real challenge since everything was new to me and I had to learn all these technologies at the same time. It was funny because I found the challenge easier than I expected it to be 🙂

In this post, I will share my experience on building ChessHub.io and I will try to summarize some of the mistakes I made.

First of all, let me begin with the positive parts:

  • Using Javascript across all the stack is a real advantage: you have to master only one language
  • Using JSON across all the stack makes it easy to pass data from one layer to the other. I remember the pain of mapping data with Dozer from the POJO to the DTO to the View and back again, arrrgh!
  • Application packaging is much easier than the jar, war, ear files to deploy in a Java app server
  • You can forget about endless JVM tuning of your Java app server

That said, a stack like Node, Express, Mongo is not suitable for every application and is not intended to replace the good old Java app server backed by a relational database. Here are some use cases where Node JS is a perfect choice:

  • Real time data intensive apps with many concurrent users : games, chat, social networks
  • System/Application monitoring dashboard
  • Data streaming apps
  • Server side proxy

In contrast, Node is not suitable for CPU intensive apps since it is single threaded.
In the same way, Mongo DB is not suitable for apps that require transactions, in such cases, you can keep the RDBMS you love.

One of the mistakes I made was to think synchronous using Node JS. Let me show you an example.
In ChessHub.io, I want to show a random quote from a chess master on the home page, so here is a pseudo code I wrote in the very first stage:

quote = loadRandomQuoteFromDb();

This is actually a blocking snippet since it will wait the database to respond with the quote to be able to continue to the next instruction. When you spend several years thinking synchronous, it is natural to make such a mistake. After investigation , I realized that this way of thinking when using Node is completely wrong. A asynchronous version of this snippet is:

loadRandomQuoteFromDb(quote, function() {

In this configuration, if the database take some time to load data, Node can continue serving other requests and when the data is ready, the callback function will be called asynchronously.

That was my retrospective on building ChessHub.io. If you got the same experience, do not hesitate to share your thoughts in comments.

See you soon 🙂

Subscribe to our newsletter for more code resources and news

routerLink with query params in Angular html template

routerLink with query params in Angular html template code snippet Continue reading