Good Bye to LAMP Stack and Hi to React and Node

Author: Shiksha FE Team

Modern websites are identified with speed, accessibility and minimalistic UI designs. To achieve these milestones and maintain competitive edge, organizations regularly buff up their technology stack. The real dilemma is that the internet and digital landscape is ever-evolving and planning for any major overhaul in the tech stack triggers site-wide update.

We encountered this issue in late 2016 and early 2017. Our team had successfully used LAMP Stack for nearly a decade. However, the challenges kept mounting — performance issues, very tight coupling between modules in code and at backend level also, lack of a component based approach, etc.

We adopted different approaches and made extensive changes in the code to improve performance. We even went to the extent of decoupling the code without any previous experience. However, the results kept falling short of our own expectations.

Another major decision was to do away with the existing architecture that was written in PHP (I truly understand the pain of any PHP developer) and move to a different platform altogether. We had two options before us: either we could shift to the latest stable version of PHP or make a complete shift to new technology. Either way, the site would have undergone major revamp.

The trend for PHP in the market was rapidly dipping and emerging technologies such as Python, Ruby and Node JS were increasingly adopted by tech teams in different organizations. We went ahead with React.js as our front-end framework and Node.JS as our server side framework due to these factors:

• Building modular approach towards code creation, testing and deployment
• Code decoupling
• Support from communities and other developers
• Impact on SEO and web performance

Initial Brainstorming

First step was to decide on the new architecture for our backend/frontend. After a lot of brainstorming, we decided to move from existing Monolithic Architecture to MicroService Architecture and the prerequisite for this change required some new front-end library or framework that would coordinate nicely with the new backend system (Micro Services).

POC / Experiment Phase

We started experimenting with different front-end libraries or frameworks and finally zeroed down on three of them, i.e., AngularJs, VueJs and Reactjs. We developed our POC and compared them on the following grounds:

As per Stack Overflow’s annual Developer Survey ( https://insights.stackoverflow.com/survey/2019), React is the library, developers say they want to work with most of all if they haven’t done that already. Node.js takes the second spot on the list.

The major factors considered while comparing include Development Speed and Productivity, Popularity, etc.

Based on its strong community support, roots in conventional javascript and lightweight framework, we opted for ReactJs as our front end framework.

Development Phase

During development phase, the biggest challenge was to adopt a correct approach for development that would benefit us in SEO, User Experience and Performance.

We were meddling with several approaches at that time:

• Maintain Server Side Code in PHP and serve the same to Crawler (Google etc.) and develop Client Side in ReactJs.
• Serve Client Side Code (ReactJs) to Crawler (Google etc.) via using PhantomJs and serve client side code separately
• Move forward with Isomorphism approach.

As you might know, all the pages on Shiksha.com can be accessed by both the crawler and the user in the logged out state. So, the main objective was to ensure that google and other search engines (crawler) could easily crawl the page (for that we need server side rendering) while the client side rendering too was necessary to give a seamless experience to our users.

Well, after thoroughly reviewing the pros and cons of every approach, we decided to go with Isomorphic Approach.

What is Isomorphism?

Isomorphism as applied to web development means rendering pages on both the server and client side. It usually implies the use of JavaScript and Node.js/Io.js because they allow for the re-use of libraries, allowing browser JavaScript code to be run in the Node.js/Io.js environment with very little modification.

As a result of this interchangeability, the Node.js and JavaScript ecosystem supports a wide variety of isomorphic frameworks such as React.js, lazo.js, and Rendr amongst others.

The three main reasons developers rave about isomorphism are:

• Better Search Engine Optimization (SEO)
• Better performance
• Better maintainability

Final Tech Stack

• Webpack — Webpack is a module bundler. Webpack can take care of bundling alongside a separate task runner
• WorkBox — Workbox is the successor to sw-precache and sw-toolbox . It is a collection of libraries and tools used for generating a service worker, precaching, routing, and runtime-caching.
• pm2 — PM2 is a process manager for the JavaScript runtime Node.js.
• ReactJs — React is a JavaScript library for building user interfaces. It is maintained by Facebook and a community of individual developers and
• Redux — Redux is an open-source JavaScript library for managing application state. It is most commonly used with libraries such as React or Angular for building user interfaces.
• ExpressJs — Express is a light-weight web application framework to help organize your web application into an MVC architecture on the server side. You can use a variety of choices for your templating language (like EJS, Jade, and Dust.js).
• NodeJs — Node.js is a framework for writing server-side JavaScript applications. It is built on top of the V8 JavaScript runtime and uses an event-driven, non-blocking I/O model that makes it perfect for data-intensive, real-time applications.
• npm — npm , short for Node Package Manager, is two things: first and foremost, it is an online repository for the publishing of open-source Node.js projects; second, it is a command-line utility for interacting with said repository that aids in package installation, version management, and dependency management.
• Babel — Babel is a free and open-source JavaScript compiler that is mainly used to convert ECMAScript 2015+ code into a backwards compatible version of JavaScript that can be run by older JavaScript engines.
• ejs — EJS is a simple templating language that lets you generate HTML markup with plain JavaScript. No religiousness about how to organize things. No reinvention of iteration and control-flow. It’s just plain JavaScript.

Challenges faced

Problem: In our application, a single large bundle with all of your code becomes a problem for startup time. How to start breaking app into separate bundles and load them dynamically when needed?

Solution: We had a lot of discussion within the team and across other verticals to no avail. After engrossing in R&D over internet for a long time, finally we stumbled upon the solution i.e. React Loadable library which is used for component-centric code splitting.

Problem: How to gracefully reload the server without stopping the runtime processes and also load balancing at traffic at server level?

Solution: pm2 — It is an excellent production process manager with a built-in load balancer. Keeps the applications live forever, allowing them to reload without any downtime.

Problem: A lot of performance related issues came up after Google made changes in algorithm.

Solution: We made some changes in how our resources are loaded.

Problem: In Redux, data of different module was retained while browsing from one page to another (server side) and due to which page size drastically increased.

Solution: On the server side while accessing a particular URL, we flush all other redux data apart from the current one.

Problem: How did we handle CORS issue as our Frontend & APIs are hosted on different domains?

Solution: Well, we set ‘Allow Control Header’ at API server.

Conclusion

So did we succeed in our mission? Well, the performance indices and website metrics tell the complete story.

• Performance of pages are much better as compared to before. Most of the pages have Google Page Score > 90 earlier which was between 70–80.
• Reusable and Optimized Components are available to use on multiple pages / modules.
• Rendering and DOM manipulation are much faster than before.
• Front end is completely segregated from the backend server.
• Due to SPA behaviour, user experience has drastically improved.