Codeforgeek is re-designed from scratch and we built it by using multiple technologies. In this article, I am going to explain about the technology stack of Codeforgeek.

Before this release, Codeforgeek was running entirely on WordPress. We had built a custom WordPress theme for it and used various plugins to achieve our goal.

Read our announcement post: Announcing Codeforgeek Version 5 – One of Our Major Upgrades

In this release, we moved to a full-stack JavaScript stack. You are currently reading this article served by the custom Node.js server.

Let’s list down the technologies we used and then will learn about them in brief:

  • Front end – HTML,CSS,VannilaJS,jQuery,Vue.js
  • Backend – Node.js, ExpressJS, Pug
  • Databases – MongoDB, Redis
  • Queue – ZMQ
  • Server – Nginx with ngxpagespeed module.
  • Static files storage- Amazon S3 bucket.
  • Static CDN – Amazon Cloudfront.
  • Content management system – WordPress.
  • Content delivery network – Cloudflare.
  • Email – Google SMTP.

Architecture diagram

We followed the microservices architecture principles to built multiple services that perform their tasks. We have following microservices as of now:

  • Content service.
  • Page-view sync service.
  • Rss generation service.
  • Sitemap generation service.
  • Communication service.

Services are deployed independently and they perform their own tasks without depending on other services. The communication happens between each service using the ZMQ message protocol.

Here is the sample architecture diagram for content service.

codeforgeek architecture diagram

As you can see in the diagram, Nginx sites on the top of architecture and does the following task:

  • SSL negotiation.
  • Gzip encryption.
  • Load balancing.
  • Javascript optimisation.
  • CSS optimisation.
  • Cache headers.
  • Compression.

Nginx performs the load balancing and forwards the request to one of the Node server instances. We use least conn load balancing strategy hence the Server with the least workload gets the request.

We run 4 Node.js server instances on a different port (Not in cluster mode) that allows us to perform load balancing using Nginx.

At the database layer, we are using MongoDB to store content migrated from WordPress and caching the results of the query in Redis. When a request comes, Node servers check whether the cache copy of the database call exists and if it does, it uses the cached response from Redis hence putting less load on Database and also increasing the time to response.

The design decision is to have just one database call for each article request.

I will explain how to cache MongoDB with Redis in a separate article.

Technologies and tools

Let’s discuss in brief the technologies we used to build this website.

For front-end, we used libraries such as jQuery to make the website interactive and we used Vue.js to build courses as a single page application.

We use the Server-side rendering technique. We use the Pug templating engine to generate HTML pages and serve it to the user using our Nginx server.

MongoDB is a primary database that stores posts, courses, users and all the meta-information. We cache the commonly used database query results in Redis for faster throughput and less load on MongoDB.

All of our static files such as images, JavaScript, CSS is stored in the Amazon S3 bucket and served using Amazon Cloudfront service for low latency and fast response.

The admin section i.e to write content we still use WordPress and both systems link each other using webhooks. I believe that the combination of WordPress admin and high-end custom server to serve content is the best way to use the most of these technologies to yield amazing results.

For communications, we use Google SMTP service to send emails to important events.

Deployment and monitoring

We use Github private repository to store our code and Travis CI to perform the deployment to our Server hosted by awesome DigitalOcean.

We use PM2 to run each service and Keymetrics for monitoring. Check out keymetrics if you are running Node in production.

READ: Nodejs monitoring using PM2

What did we achieve

<1 sec load time (time to interactive)

Yup, that’s right. Here is the proof.

Loading time screenshot of a home page:

homepage speed pingdom

Loading time screenshot of an article page:

article page speed pingdom

We achieved what we wanted and it’s really proud feeling 😀

How long it took to build

From concept to design to development, it took us solid one month to build (approximate ~60 hours, I have a day job too) and a week to test in staging.

What’s next

This is just a start. Our goal is to build Codeforgeek as a community-driven website where readers like you can come and write about their project, experiences, case study and build their own online presence. The next phase of Codeforgeek will be focused on community based contribution service.

Did you like our work? Check out our services page to hire us. We can build a similar kind of software for you to manage and serve content on a large scale with new technologies while still leveraging the best part of WordPress.