 All right, so hello everyone. I'm Abhinav Rastogi. I'm a UI developer at Flipkart. I've been there for around the past two years now. So I'm going to be talking about Node at Flipkart. So we have been working on this framework for some time now, around five to six months. And our current stack, let me give you a little background on that. So our current stack pretty much looks like large part of it is in PHP at the back end. And the usual HTML, CSS, JavaScript at the front end. So now, obviously, with a PHP-based stack, it mostly depends on the implementation that you have. And as time goes on, as new technologies come in now, we can run JavaScript on the server and things like that. There's, of course, always room for improvement. So that's where we decided to look at a more JavaScript oriented or a more, in general, different approach from the existing one that we had. So first of all, I think a lot of people have already talked about jQuery. Please, no. I mean, we have been there. It's a heavy library. You don't want to be so dependent on it. We can pretty much do everything without jQuery that we have been doing. As for cross-browser friendliness, we have a lot of ways to handle that too. So yeah, we should try to avoid that as much as possible. So coming to what all we do on the front-end, we look at a lot of framework. So we have so many things on the front-end. This is just a short tag cloud of what famous front-end frameworks there are already out there. Some of the most popular being Angular and JavaScript MVC and Luna from Asana people at Facebook. So there is a bucket load of frameworks out there so that we can use. But then again, this was two years ago, three years ago, that these frameworks started coming in and becoming popular. But now as we can execute JavaScript on the server side using Node, more and more frameworks are popping up now for the same thing for doing it on the server side. So let me take a quick feedback from you all. What do you think, how many Node-based frameworks, web frameworks are there right now? Any guesses? So I'm getting numbers like 6 and 10. So here's a short list of a number of frameworks that we have, and this is not even half of it. So there are over 30 to 40 web frameworks built in Node.js, not specifically Node.js, but in JavaScript meant to execute on the server side. So yeah, now the biggest problem when you have such a big list is they all do, they are very, some of them are pretty solid frameworks like Meteor and take some other example from here, like Flatiron and Express. So now all these solve very specific problems sometimes. So the problem that comes to your mind is so when we start working with a new framework, so I mean when we at Flipkart decided, let's try something else, let's try to move away from PHP and let's move into something JavaScript based. So the biggest problem is how do you evaluate these frameworks? How do you decide which one is the best, which suits your needs? So that's the biggest problem that you have because none of the frameworks will exactly do what you want it to do. So the solution that we came up with that we thought of at Flipkart was, if you want to do something properly, do it yourself. So that's where we decided this approach that let's try to build something and as we work on it, we try to do exactly what we need, nothing extra, nothing more, nothing less than that. That's how we thought that we will arrive at a framework, okay, now we know what we need to do. So let's see, let's then evaluate what frameworks are there in the market, which will do it for you, all right? So this is what, this is one of the things I'm going to be talking about today, how we built a WebStack in Node at Flipkart. Now, building a WebStack is not really that difficult these days, as you can see by the number of frameworks. It's a pretty standard approach, how you build a WebStack, all right? So this is one thing I'm gonna be talking about and the next thing is more importantly, once you do build a WebStack, how do you get Node into production? See, I mean, people frown upon it a lot, even these days. Node has been around for what, one and a half, two years now, but it's still considered to be sort of, people are like, oh, it's cool, you're trying Node, but are you really sure it's gonna work? You get that kind of reaction from people when you go in that direction. So yeah, these are two main things I've been talking about, the new framework that we've been working on, how we got to it, what are we doing in that, and when are we actually launching it? And secondly, how, what problems you're facing, what we learned, and what we have not yet solved of getting Node into production. So this is the basic philosophy that we are in following. This is just some, you know, mumbo jumbo, a WebStack to build rich UIs for the next generation, embracing progressive enhancement. Don't concentrate too much on this. So this is what your typical Web framework will look like if you're making anything like that. So you get a request, you have to hit a bunch of APIs for that request, let's say for a typical flip card page, you have to hit like session card, search and product. So all of these APIs will give you some data which you compile it into, say, JSON, if you're working in JavaScript, you pull up your templates from your file system or CDN or wherever, you compile it together, you render it, you get the HTML in it, serve it to the client, plain and simple. That's how a Web framework works. Now, what we did over this was to try and optimize this. First, of course, the biggest benefit you can get as Sunil also talked about earlier, you just parallelize these calls, right? That's, that JavaScript makes it very easy. It's possible in other technologies too, but JavaScript is asynchronous and parallel by nature, asynchronous at least. So we get to do all these calls in parallel and that gives you a huge benefit, right? And you use promises to do that. So that solves one part of the problem, right? That gives you a huge benefit. The other thing that we did on this, over this, is that, see, so this is what you're doing on the server side. So what you do after this is, suppose you send your JSON also to the client over the same HTTP connection and you also send your templates to the client over the same HTTP connection. What this allows you to do is to render this, to do the same things again on the client side. I will get to that in a minute, but keep this in mind that now we are sending not just the HTML, but you can also send the JSON and the templates to the client. How that helps, I will get to it. So as I said, the question, okay, why node? There are so many other JavaScript technologies that you can use on the server. You have got Rhino and many other things like that. So why node, right? So first of all, as I mentioned, it's parallel, right? It's async. The async, the callback nature of node, in general, gives you a very big benefit. If you make those calls in parallel using promises, you know, you just fire off calls to five APIs. You wait for all of them to come back. As soon as all of them are back, you just, you know, all your promises get resolved. And you simply take that data, compile it and send it to the client. Now, suddenly, you know that, you know, out of those five APIs, okay, this is the fast, slowest one. This is the one I need to optimize, and that is your only bottleneck. So that's one big benefit there. The second thing is it's lightweight, right? And it's pretty much the best available JS execution environment on the server side. You'll be evaluated things like Rhino and all. The thing is node simply just works, right? Out of the box. There is not much overhead to it. The next thing is it has a great community, right? I'm pretty sure I don't need to convince you guys about using node pretty much. I think everyone is already using node here. It has a great community. You know, you have an issue. You can just go and talk to so many people and you know, seeing the turnout here, then that's a good proof that we have a good community going on. And yes, there's a module for that. You talk about node, you talk about any damn thing you have in your mind. I'm pretty sure there's a module for that. I mean, take example of what someone just talked about, right? You have a module for the Internet of Things also now. I mean, the Internet of Things is not here yet, but the module is already here until we, you know, working in node. So that's that. So now let me talk about some of the challenges we faced at Flipkart as we are trying to build this framework. Yeah, so first of all, it's called like front-end JS with a pH, like front-end JS. So we faced a lot of problems as we were working on this. So we started, as I said, about five months back. And so first we decided to sit down and, you know, list out what do we want this framework to solve? What are we trying to solve? I mean, we have a website already up and running, and then we are already trying to optimize it. So what else do we want over this? So the biggest problem we were seeing at the current time is code-maintainability, all right? So now it's just a fancy word, but what does it really mean? So when we talk about code-maintainability, you know, we, three, four developers sat down, discussed all this, built a framework, all right. You know, that's all well and good. But what happens when you release that framework to, you know, your team of 30 people? What happens when the rest of the company starts using it? And I'm not suddenly talking about 200 people. What happens when you release that framework out in the world? You know, now thousands of people are using it. So code-maintainability is primarily what you do, you know, to keep that code from gathering so much junk over time, you know. What happens with our existing code bases? I'm pretty sure everyone faces that problem. You know, you have some features. You, you know, there are 30 developers working on it separately in different branches on Git. And, you know, people are putting stuff in. They say, okay, this feature is missing. I need to change something. They just put a hack in it. Okay, I will come back to it later. And that's it, right? That hack stays on for a long time. That's not what good developers do, right? What good developers do is they put two dos and comments in the code that I'm going to fix this hack later, right? So that is one problem that we wanted to solve to prevent people from thinking that hacks are okay. So one thing that really helps us in that direction is these tools like class and load-ash. Now JavaScript by itself is not an object-oriented language, right? I mean, it has objects, but it's not really object-oriented in the classical sense, you know, supporting inheritance and stuff like that. So class is a library node module which helps you achieve that. It helps you write, you know, a classy code by classy, I mean, in both terms, you know, both senses. Similarly, load-ash is a tool which is a fork of underscore. I'm sure pretty much everyone would have heard of underscore. So yeah, it helps you keep a lot of, you know, avoids people from, prevents people from adding small, small functions here and their helper functions which, you know, are already there and cross-platform and cross-browser support. The next problem we wanted to solve was high availability. Now, a high availability would mean something like, you know, 99.99% uptime, but what does it really mean? See, from our standpoint, high availability would be something that, you know, the server should never go down. From a customer standpoint, high availability would mean that at any time if they want to buy something, they should be able to open the website, browse to a product, you know, browse to their website, pick a product, add it to the cart and order it. So the core principle behind high availability is not just having multiple servers, but what happens on those servers. So you have to keep in mind that, you know, node processors have a tendency, you know, it's, you have to keep an eye on it, simple as that. You have to keep that process running. They have a tendency to crash sometimes. You can run out of memory. You can run into JavaScript errors, all right? It's not a, you know, very strongly typed language. It's very easy to make mistakes in JavaScript, all right? So we evaluated many tools or libraries to help us with that. One thing that we figured was, you know, trying to use something like forever. It's a very simple module. It runs itself, you install it globally, and it runs itself as a daemon in the background. And you say, and you tell forever that, you know, run this process, suppose app.js for me, and finally, and it will watch over it. The moment it dies, it will try to respond that process again, right? That sounds pretty simple. So the architecture that we tried to build was, okay, so forever calls this app.js, who is a master process, and now you have four cores on your machine, right? Four or eight or 16 cores on your server's class machine. So what do you do then? Right, Node will typically just, you know, take one core and run on that. So one obvious solution is forks and children, and Node has very good APIs for that. So that's what we were doing. Forever would, you know, create one process, and then that process will again spawn more children, and each of those children will then take requests on the same port. But we pretty much, you know, pretty soon ran into serious problems with that approach. So we tried other things. We tried PM2. That's a library called Process Monitor 2. So now that is a bit, you know, it's not as easy to implement as forever. It's more stable. But yeah, we didn't have a very good experience, but it was getting, again, quite complicated. So we came to a very simple solution, just write a shell script. It took hardly 15 lines of, you know, coding in Unix to create a simple while loop which just watches over your node processes, and there's no need for parent and child anymore. All you have to do is just launch three processes. You can use the task set command in Unix to bind your process to one of the cores, you know, bind the affinity. And you just, you run a kill-minus-zero command on your process, and it will tell you the status whether it's running or not. Put that in a while loop. If it crashes, respawn it again, end of story. There's no master process, no child process. There won't be any zombies, right? Becomes very clean and simple. Plus, you know, the less of libraries you use, the better off you are, right? There's less things to break, simple as that. The next problem we wanted to solve was testability. Now, of course, the reaction is, like, test cases, like, let's not go there, let's not do that right now. Because, obviously, I mean, it's, you know, everyone has a tendency to go for the low-hanging fruit, and test cases are not that, all right? But let me tell you this by experience, the experience we've had working on this framework. See, earlier, we didn't have test cases, right? Not much of testing, like, you know, unit tests around front-end code. It's pretty complicated to do front, you know, unit test cases for JavaScript code, especially the UI part. But for something like a framework, it's pretty easy to do it, you know, and if you use the right tools. For example, we, these are the tools that we tried out, like, all right, so we evaluated a lot of things. So in testing, there are basically two main things. One is your test runner, and one is your assertion library. So Mocha is your test runner, right? And there are other test runners, like vows.js and things like that. So they allow you to run test cases over your code very easily. And things like Chai, these are assertion libraries, which allow you to do, like, you know, expect this value to be equal to this value, and they will return true or false accordingly. And similarly, Istanbul is a library which allows you to do code coverage. So these are the tools we, you know, found out and worked with, and, you know, after a lot of experience, you realize that these actually work pretty well and make testing your code easy. And take my word for it, write test cases for your code as soon as you start writing your new code, right? Coming back to it later never happens, and it's very difficult. If you started the beginning, it's easy to maintain and increase those test cases, but it's difficult to come back for an existing code and write test cases. And test cases do help a lot. I mean, they will cover corner cases which you couldn't have imagined. So obviously, you know, you're working on any kind of project. You want, your performance is a key metric. You want it to perform well, no matter it's running on the server or on the client. Performance is key. Their resources are always limited, always. So you have to consider performance. And especially for node, you know, when you're running JavaScript on the server side, you have to profile the code. That's the only way to check the performance. See, on the client side, you know, you have the Chrome DevTools. You can see what are the timelines and stuff like that. And you can do, you know, frame, how many frames per second your code is running at, or what kind of rendering you're doing. On the server side, you need different kind of profiling. So you need to do mostly CPU profiling. That's the most basic kind of, you know, performance test that you can do. So tools like Look is, that is one tool that we came across. It helps you quite a lot. So what Look allows you to do is, it will let you look into the CPU at any time. It can collect 10 second, 20 second windows. It will tell you exactly what was running on your CPU during that time, what programs, what processes, what functions of your code were executing. So you can learn that, oh, this function is taking a lot of time on my CPU. So maybe I should optimize it, right? Similarly, Detrace it is a tool which allows you to generate flame charts. Now, flame charts do a similar thing about CPU profiling, but then they will draw a proper chart for you. That what does, you know, what all was executing and which functions are stubs that, you know, the function itself is taking a lot of time, or is it calling other functions intern which are taking a lot of time. But to put it simply, all of it boils down to one main thing that is the event loop. That's a very crucial concept to understand in Node. If you're working with Node, if you want to improve your, you know, work on the performance aspect of it. The event loop is something in Node which the Node process itself, the Unix process Node, it will call your event loop, right? There's this one event loop which is executing which will get called every iteration, every next tick of the processor that function will be called. And anything that you do, any code that you write, let's call it the user land, right? We are the users of Node, so whatever code we write in the user land, whatever functions we call, whatever variables we create, no matter what command we give, gets pushed into this action queue that Node has. And when the event loop executes, it picks up the next item in the action queue, executes it and goes back to sleep. And then it will get called again in the next tick, and it will again pick up the next item, process that and go back to sleep. Now what happens when one of your functions in the event loop suddenly, you know, one item on your action queue starts taking too long, right? It takes more than what, you know, it lasts longer than the time that the processor gives you for that to execute. That means you have blocked your action queue, right? And that means nothing else, no matter how asynchronous you are, no matter how parallel you are, right? At the end, there is that one processor, right? One core on which Node is running. That guy won't be able to do anything else. He can't take any more requests from the client, he can't do anything else. So that means you have to keep a track on your event loop that it should not get backlogged, you know, there should be nothing which is going beyond its limit. So these tools like look and detrace help you debug your event loop. And interestingly, in Node, you can actually get the event loop lag by using tools like 2BZ. There's a tool called a library called 2BZ. It will give you the lag that your loop has, and that lag is nothing but the milliseconds that your loop is behind from the actual, your code is behind from the actual calls that are happening. So usually it's like, you know, 2MS, 3MS, 5MS, that's fine. But if it starts going over, suppose 100MS, then you know you have a problem. You can simply raise alerts on that. That helps a lot. The next problem we wanted to solve was code reusability. You know, so the first thing that we understand from your reusability is, you know, modules. You create components, you create functions. You know, you talk about carousels. You create a carousel that's reusable. It's reusable if it can, you know, show a scroller for, it can show a scroller for your images. It can show a scroller for your products. But that's not what reusability means these days. Reusability also means, you know, code that is reusable between server and client. So then we need to talk about components, right? It's not just about modules on the front end. It's also about components. So the approach that we went with was common JS. Again, like other people talked about AMD's one approach. That's, you know, all pretty much the same things. You use require.js and stuff. It pretty much solves all your problems, right? Just go with it. No need to bang your head over it. The next problem you need to solve is templating when you're working with modules. So there are so many things. If you use something like express, it comes by default with jade. We tried handlebars, but, you know, it's painful working with so many helpers. You know, if you have, like, array in which the key, you know, if an object in which the keys are changing, handlebars just, you know, loses its mind over it. So you have to write helpers, custom helpers and all that. Then we tried underscore templating. That worked very well for us for a long time. So for a long time as in the development phase. So, yeah, that works pretty well. That's when we came across React.js, you know, and we realized that it's doing a lot of stuff that we were already doing. And that's what we aimed it to do, you know, actually. That, you know, let's try doing stuff ourselves and when we see that, okay, this is what we want to do, then we look for a library which actually does that and it will probably do it better because they can cover more corner cases. So that's why we started using the React.js and believe me, it's amazing for these kind of things. So this is the biggest benefit of React.js that it gives you right once or anywhere. You know, it sounds like Java, but that's not such a bad thing. So the one thing that it gives you really good is, you know, you can now render on the server and React.js and node and suddenly you are, you know, rendering on the server and as he just talked before me, you know, rendering on the server gives you many benefits, one of them being, you know, your responses are cacheable or whatever you generate your HTML, you can cache it. It's reliable, you don't need to depend on your client anymore, it's running JavaScript or not, you're serving HTML to them anyway. It's SEO friendly. You know, all search engines don't execute JavaScript, not everyone is as smart as Google, so you want to be SEO friendly. So, you know, pumping out HTML is really good for SEO. Plus, it's an optimized first friend. You take, you know, 50ms extra on the server, serve it to the client and the moment he downloads the page, the HTML, he's ready to go, he's seeing your page. You don't need to wait for JavaScript to load and stuff like that, but in this day and age, when the, you know, the browsers and clients are so powerful, it doesn't make sense to render only on the server. You know, what about all that extra processing power that's available and, you know, you've got Android phones, iPhones in your pocket, pretty powerful, they can do all that your server can do. So rendering on client gives you very obvious benefits, you know, there's less load on the server. You don't have to, you know, get into engine, yeah, I mean, as simple as that, you get less requests to the server if you're doing it all on the client. Secondly, the perceived performance goes up because you don't need to go to the server every time. You make some change, you make a click, it just refreshes on the client itself. It's very fast. Plus, you can build much more richer UIs, again, because of the dynamic nature. So the simple answer is do both. But, so React allows you to do that. But you need to keep in mind that there are some issues that can come up with such code. So this concept is called isomorphism, right, a code that can run on both server and client. But with isomorphism, you need to take into consideration a few things, things like logging. You know, console.log works both in Node and your browser. But you obviously, you don't want to log your warnings and errors to the user's browser. So you need to use some logging libraries. Now they need to take care of whether they're running on the client or server. So you need wrappers around that. Similarly, you might have environment-specific code, for example, you know, getting the host name or some other things like that, which can only run on the server. Or there might be some other things which only run on the client, right, you know, I don't know, like WebRTC and things like that. Similarly, what about external HTTP requests? So as I said, you know, you need to hit these three, four APIs. Or can you hit those APIs from the client? Maybe, but not directly. So you know, from Node, you need to hit it using the HTTP module or Super Agent or something like that. But from the client side, you need to hit it using an XML HTTP request in your normal Ajax. So who takes care of that, right? So that's where you need to consider that, you know, if you're writing isomorphic code, you need to make sure that you write wrappers around such code so that you don't run into problems later. So the next problem we wanted to solve was responsiveness. Now, see, that's a very big problem in general, you know, responsiveness in terms of media queries, until now everyone was trying to avoid that. So we also tried to avoid it. Responsiveness, is it really useful? Does it work for everyone? Does it work for e-commerce? Maybe not, but these are things that, you know, it's better to test them out. So yeah, that's one problem we are not solving right now because honestly, I mean, there are bigger problems to solve out there. So then the next thing was cross-device and cross-browser friendliness. Again, IE, Android 2.3 is like the IE of the Android world and cloud browsers, it gets very complex, very fast, right? So the solution to that, keep it simple silly. Don't worry too much about these things, at least that's what we did. We just checked one thing, you know, is the minimum amount of JavaScript that we require, is it supported? If not, fine, serve the Node.js version, right? And that's where progressive enhancement comes in. You need to make sure that your website is progressively enhancing, right, and not just, you know, graceful degradation. It's the exact opposite. So you need to make sure that your site first runs in a Node.js environment. And then you talk about, okay, if JS is enabled, then what you do? For example, you submit your forms for searching, you have a search box at the top, and you have a search button. Let it be a form submit to your search URL at the beginning. It will work on Node.js browsers. But then if you do have JavaScript supported, capture the click event or the form submit event, capture those details, send an Ajax request and reload the page there, right? So that's what progressive enhancement means. So you have to keep that in mind. So now, this may sound like, you know, fan boys, and you know, like, Node is all well and good. And that, you know, like nothing can go wrong. It's not so. Node has its fair share of problems. So let me take a quick look at why not Node, right? So what are the problems with Node? So the first thing is it's relatively new. And when I say relative, I'm talking in terms of, you know, other server-side technologies, like PHP and Java. So Node has a lot of unsolved problems, right? So if you go through the Node docs, you know, you are using some certain features of Node. If you one day decide to open the page on, you know, Node.js.org and suddenly see that, you know, it's an experimental feature. It's not even stable. And it might change in the next version of Node. And you know, like, shit, I put this in production. What do I know now? Right, so you have to be very careful of that. That, you know, a lot of stuff is relatively new. So you have to be careful of what you're putting into your code. As I said, there's a module for that. That's a benefit, but it's also a con, right? So it's like the Android Play Store that, you know, anyone can push anything. So the quality is not guaranteed. So you need to be careful, again, what is production worthy and what is not. So getting Node in production is more complex than it seems at first. Plus, as I said, you know, combining these two facts, there are so many unsolved problems out there, you know, a lot of times, you know, I think many people would have seen that XKCD comic where, you know, there's this guy just typing into, you know, he's searching there. You run into some issue and you Google it. And on some thread, you find out some, you know, some guy one year ago posted this, you know, I ran into this problem. And for one year, there has been no response on that thread. You know, actually, you know, one year and no one has solved this. So you only get left with two options there. Either you try to solve it yourself, which may not be possible, or you try to, you know, walk your way around that problem and take another approach. Again, both these are, you know, very time consuming things. So you need to consider that. So I think I'm running out of time. So let me quickly go over, you know, productionizing node. What is, what things do we need to keep in mind and what are the things that, you know, we ran with problems that we ran into and tried to solve. So one thing is you need to monitor and alert your node processors, right? So Nagios is one tool which helps a lot. It just monitors your system from the outside. So, you know, when your servers are going down, monitor is another useful process, very obvious thing. If you don't monitor your processor, you're gonna have bad, you're gonna have a bad time, right? You need to log it. You need to use some logging library which has standards. Don't just do a console.log and redirect the output to a file. You need to log to a file properly, right? Take care of your log levels. You need to do, you know, like info, debug, and error level and fatal errors. You need to log them separately. So it's easier to debug because it can get very complex to debug node, right? So there are other libraries. Also, Banyan is the one that we are using. There is another library called Winston, which is very promising. Okay, I think there's a very key, interesting difference between server health and rotation status. That's what we realized that, you know, server health is whether the server can serve code, can serve request, and rotation status is whether your server should serve responses, requests. So keep that in mind. That's important, okay, in QPS versus concurrency, that different QPS is, you know, incoming connection that you are getting. But suppose, you know, you are getting like 10 requests per second, and your concurrency would be how many processes are actually executing at this time. So you need to keep both of them in mind. So these are the main things that I talked about. Node in production, isomorphism, and some useful tools and modules that are there. Yep, so that's about it. I'm done. Any questions around this? Thanks Abhinav, we just have time for maybe a couple of questions because we are running a bit late. You talked about Node.js as your main stack, right? So I would like to know what was your existing stack and what was the problem you faced after that? Okay, so our existing stack is mostly in PHP, the backend. Okay. And the problem that you face with PHP is not the language, it's not with the PHP itself, but more about the implementation, right? And the current implementation that we have, you can solve it. So there are two ways to solve the scale problem. See the largest problem with Clipcard right now is scale, right, as more and more visitors are coming and you know, we have larger and larger sales every day. To solve the problem of scale, there is one way is to throw more money at it, right? Just put in more servers. But in the other ways to make the existing servers more efficient. So getting more servers works with PHP, right? But if you want to make the same servers more efficient, then we thought that maybe try some other technology. So that's where we are trying to test with Node. So the project is not completed yet. We are in process of the migration. But yes, we are seeing very positive responses with that. You're planning for a step-by-step migration or is it like a one-time migration? Oh, no, definitely. It's a step-by-step migration. So for a website like Clipcard, which has so much existing framework and architecture already set up, it's impossible to move in one go completely. You can't just move everything overnight. So it has to be step-by-step. You start by moving one part of the website or you start by moving one part of the user base and slowly and steadily you increase that until the whole thing is replaced. Okay, thank you. Any other questions? Well, I have one if you don't mind. Yeah, yeah, sure. Not related to JavaScript, but do you run your servers on Amazon? Oh, no. Yeah, because that would have been really ironic.