Little Background

I am currently working on Practo’s Healthfeed, a place where doctors and health specialists write health articles and share their expertise. If not anything else, any blogging platform needs to be good at ONE thing the most: the SEO. Any blog with good SEO is destined to get more readers than anyone else. And more readers means more SEO !

To get better SEO you have to do a lot of things right. But here we’ll only talk the most important two, the most fundamentals for good SEO:

• Making your site crawlable for bots.

• Make it FAST. Like Millennium Falcon fast !

Enters React !

When React came out, one of it’s selling point was that it supported Server Side Rendering (SSR). To make your app support SSR, All you need is a node server and an API. The modern architecture looks something like this:

Notice ! The node server acts as a mediate person between the user and the API server. So the Flow goes like this:

• User hits the URL, Request goes to the Node Server.

• Node Server makes request to the API Server and takes the data from the API server.

• Pushes the data to the APP, which in return creates the final HTML for the user.

• Returns the HTML string back to the user.

Now the whole setup is done ! Server is taking requests, API is giving response and finally user/bots are getting a fully rendered HTML page. But this can turn out to be a user’s nightmare.

Issues !

• What if API server is slow! Like 500ms response time.

One problem with the server side rendering is that it’s response time relies heavily on the API server’s response time. That means, no matter how efficient and fast app you’ve made, the user will see the white screen for atleast 500ms, provided your node server has 0 ms response time. Which is practically impossible (for now).

So let’s see the breakdown here:

• 500 ms response time from API

• 150 ms for server side rendering (yes, it takes that much)

• 10 ms for node server

• 150 ms network latency

So a user will get response after almost 810ms ! Now, of course these are just average numbers, but in real world, it can be lot worse. Since we don’t have much control over the network latency, we’ll keep that out. So the server response time is currently at 660 ms.

To improve the situation, we’ll first catch the biggest fish: API response time.

Enters Redis !

Redis is one of the most powerful data-structure store, which is super fast and efficient. You can store anything in there as key value pairs. Integrating redis to store the node environment is super easy. If we store the API result in the redis, we can save our network trip to the API server.

So now, whenever the user makes some request, the node server will query the Redis if it already has the response. If it has, it’ll directly pass it to the app for rendering and finally return the HTML string. If it doesn’t have the response, we’ll go ahead and call the API and now store this result in the redis before passing it to the app.

The new breakdown will be:

• 150 ms for server side rendering

• 5ms for the redis server (NOTE: The rendering time might be less or very high, depending upon your application size.)

• 10 ms for node server

With just caching our API responses, we have dropped down from 660 ms to 160 ms.

Squeeze More !

Although 160 ms is good, we can get more by just a small trick.

Instead of storing the API response in redis, why not store the whole HTML string itself ?

and this was the result !

The average response time fell to 20 ms !

Cache busting

If not handled properly, caching becomes a pain in the ass. People start constantly reporting older data/bugs become common. So with great cache, we also need a good cache busting strategy. Usually We have two cases where we have to clear the cache:

• When author updates the article. (When data updates happen)

When an author updates something, he wants to see the changes reflected immediately ! For this, we created a small param cache=false. Whenever the url is hit with this URL, the node server makes and API call instead of fetching data from the redis cache. And hence the cache is updated with the newer data.

• Whenever you deploy !

Whenever you deploy, new chunk hash for js and css files gets generated. This means if you’re storing the whole HTML string in the cache, it’ll become invalid with the deployment. Hence, whenever you deploy, the redis db needs to be flushed completely.

Conclusions

Node is fast. So is React ! But sometimes we need to add a new player to achieve that impossible goal without sacrificing any user experience points. Redis is awesome. Use all of these wisely.

Javascript community is exploding. And React is one of the biggest buzz word of it. Everyone is choosing React as their main framework to make any new web app, Android App, iOS App and even TV apps ( Yes, Netflix !).

Why you should choose React for your next project ? What makes it so great ? Some say it’s speed. If you think that’s the reason, you should go use vanilla javascript. Not just vanilla, There are many frameworks that can perform better than React. Mithril is one good example. So if not React, what makes it so popular ?

Components !

One should always write code that is easy to delete, not easy to extend.

When you start thinking your project in terms of small modules, like lego blocks !, everything becomes so easier. With React, one can easily achieve this. In fact the core of React itself is built around modular principles. To think it more clearly, think everything is a component. A button, A slider, A navbar, a sidebar. Everything is a component. There are smaller components which can be reused across anywhere in project. And these components combine to create bigger components. But what advantage does breaking our project into components gives us ?

• It makes code reuse super easy ! Not just inter-project, components can be reused across projects.

• Lesser bugs. Each component is self sufficient. Overlapping is way less.

• Easy to debug. You’ll know easily which component needs tweaking.

• Easy maintainability. Changing something means changing one component. Usually it doesn’t affect other components. Same of adding new components.

It’s a library. Not a framework

React is just a View framework. The V in the MVC. And it’s even pretty good at it. But how does it makes our life easier ? With just V, we have a wide variety of things to choose from. We can choose what we want for model layer. we can choose if we want routing or not. And the way React is made, it’s compatible with almost anything. It’s like oreos. Everything goes with oreos. It gives us liberty to choose the best tools for the job. This also allows us to easily replace one library with the other with less.

In many big frameworks, such liberty is not there. You have to use the same router, it comes with. You have to use the same network library it comes with. Even if you choose to use something else, you cannot get rid of inbuilt tools. It’s there. Always.

This is one of the reasons how React got such a great community. With react as a great View Library, Redux came as a great data handling library. React-Router came as a great routing solution. And so on. More on these later.

So being a library gives us freedom. Which is awesome !

Functional Programming

React uses functional approach for creating UI elements. The core of React is functional. This enables us to make stateless components. You pass data to pure functions, and they return back rendered elements with that data. This makes reusability of components very easy. One can pass different types of data to render similar looking components, sharing the same component. It also helps in easy debugging and great control over the data and it’s flow.

It also enables us in making great dev tools like hot reloading, time travelling etc.

Hybrid Applications

React is great if you are making a client side application. We will always want public (outside authentication walls) apps to be server rendered because of obvious reasons (SEO). But there was a reason that world moved to single page apps (SPAs). It was getting in the way of app performance and user experience.

There is no need to fetch the entire document every time you open a link on the app. In universal apps, Every time you open a page for the first time, the server fetches the data, pass it the React, generates the markup on server itself and finally sends that markup to the browser. So the first page is rendered server side.

All the subsequent views are rendered by the browser itself by making data requests to the API directly.

So this gives us the best of both worlds. A SEO ready app, and a fast rendering, user friendly app.

Enough of why we should use React. Let’s discuss

Why not to use React ?

Speed: React uses Virtual DOM. Which makes DOM manipulations faster. But will it make YOUR app faster ? Does you app does intensive DOM manipulations ? Most of them don’t. Here is an example shown in React.js 2015 conf.

Same app was made using React and Angular. You can see the difference in rendering.

• AngularJS

• ReactJS

But with changing just one line in angular code, this happens. From this, the biggest learning is that good code and timely optimizations can only make your project faster, not the choice of framework/ library you use.

Learning Curve: React is just a view library. To make a complete new application, a new person needs to learn all the other libraries/modules.

Final words

Use React because of it’s code structure and modularity. That is where a lot of dev productivity is saved. Use React for its ease of server side rendering. Use React for its awesome growing community and support.

there's an app for that

Update 2 (2016): This was a college project Idid back in 2013. Now the app is no more available.

Update : This app is now available on the app store. Check it out here.

Experience the app here.

Everybody loves parties. And why shouldn’t one. Parties are fun. They are wild. But real problems starts after the party. There’s always a person who gets the responsibility of dropping everyone home after the party, no matter how drunk they are. Now it is up to him to decide whom to drop first and then next . . . In what order should he drop all his friends so that he does this in minimum distance or say minimum time. This problem is not just specific to the party guys. Its a general problem that we face everyday. Like, in what order to go shopping ,eat food and watch a movie on a same day.

This problem has a name in mathematics, “Traveling Salesman problem”. According to this problem, a salesman has to start from a specific point, travel all the cities listed, and then come back to the starting point. And he should do all this in minimum distance. Here the order in which he travels the cities matters the most.This problem is exactly what our guy faces after the party. He has to travel to all the homes of his friends, but should do this in such an order, that saves his some miles of late night traveling.

We decided to create an app that gives us solution to this day-to-day problem. For that we knew that we need some real world locations and distances between them. So we went out to use the best location service on the planet - “Google Maps”. They have the best and easy to use API that we could use. Next we needed a great interface. Now for a great interface,we decided to use Twitter bootstrap. We want this app to be used on mobiles, so we used the 3.0 version which released recently. It is really great, especially if you are developing for the mobile devices.

Today we are really excited to release a beta version “PostParty”. Here is a link where you can experience this app right in your browser. Hope you will like this and suggest some more improvements. All critiques are most welcome. Make us push this product to the perfection.