 about my experience as a Node.js developer. So I'll just tell you the title of the talk. It's the musings of a frustrated developer, and this comes from the pure vexing nature of Node.js or JavaScript, I would say, as the more perceptive of you may have assumed. With that said, I'm Shreyansh, lovely to meet you. And I write code obviously, that's why I'm here. And those are some of my handles. Please don't judge me for the last two, I was young. And I am really horrible at just making presentations. So why am I giving this talk? Why am I having a chat with you about some of the things I've learned? Because it's actually important to see some of the more easy to make mistakes while we are learning to be a developer. And I think so, ma'am here asked the entire crowd who's presenting, what is the good method of getting into the development scene? So you can imagine this to be something along those lines where I'm giving you advice or where I'm telling you what I have experienced so you don't have to do that yourself. With that said, the other reason, and as many of the engineers will agree with me, is that because no one can write bug free code, I disagree with that statement and for a very simple reason because there is a way. And I'll just show you that the way it's, you run this lovely command and then you burn the computer and then you can live as a monk, which works out very nicely if you're working with JavaScript. So with all of that aside, let's actually go into the presentation. Tour is to human and tour and produce JS. Now, I'll just tell you a couple of the things which we'll be sort of covering in this presentation. In college, we learn how memory works, right? Sadly, sometimes you forget how that happens in JavaScript because well, it is JavaScript and nothing is what it seems like. And how we are using JSON for literally everything. Then I, actually I work with cryptography and sometimes I don't really know why I've messed something up in my code. Where I log a lot because as you can imagine that I talk a lot. So of course, that translates to logging while I'm writing code. And how configuration is just my new sort of pet peeve, I would say, and express for the win, of course. So just a quick note here. I love friends. How many of you watch friends? Excellent crowd. So this is the first present, the first sort of episode I would say, the one where I forgot how memory works. And just to lay down on the application we were working with something to give you a little bit of a context. So this application gets PDF file and sort of analyzes them of how good they are. Now, when I say good, I mean how useful they are for the end users. It's written in express by the way. At lovely 2.57 AM, I get a nice notification from AWS saying that something is an alarm. And well, well, it restarted, great. No biggie, we had around more than 15 notes to sort of cluster for all the traffic which we had. But what we noticed after I think it's around half an hour was that every 20 minutes I was getting a notification and I don't know why I was getting it, but it was a failing note which would then restart and the same thing will continue to happen at infinite. So the first thought, that as a responsible sort of engineer, the first thought should be that after solid contemplation, you decide that okay, I'm gonna just go into the prod, the prod environment and I'm going to debug it. I was watching Rick and Morty, so pardon me for the interruption there. But finally, I got around to doing it and there's this very simple command. If anyone can tell me what this does. Yes, so this is an SSH tunnel which means that I'm connecting to, let's not, right. So I can basically access the port on the right which is on the system which I'm trying to access the port on the left, very simply, very simply put. And as the first thing I'll do is just get into the logging of whatever is happening in my application. And there's this lovely garbage collector in Node.js. And this is the thing I see that it's working properly but in two ticks, which is I would say a couple of milliseconds and nanoseconds depending on how many for loops you have in your application or the complexity. It was just skyrocketing for absolutely no reason. So the first question, how and who can debug this? The problem is that our code base has quite a bit of code around two lines of code at this stage. I have no idea. Okay, so 90% of that is Node modules, I'm sorry. So a couple of methods do exist to sort of debug this. The first one is core dump. Just take a dump of whatever virtual machine or application is running on an analyzer from there. Security researchers love it, I'm pretty sure. The second one is something called MDB. Now, this is not a very viable option for a very simple reason because this is a tool which is created by Joined which is sort of like, you can imagine it to be like a parent company for Node.js. And it only runs in one of the proprietary operating systems, so satellite there. And there is no debug. I'm not even going to go into why that is horrible. There is Perfmon, which is not that great, but it works on Linux events. You can get some sort of information from it, but for production, it's really, really slow. So I was having a chat with an engineer, like a senior engineer, and the first thing I hear is, are you lazy? Because back in their day, apparently they used to read RAM with chips, which sadly I can't do because I have a very high level system in my house. I'm just kidding, I don't. So what did I finally choose? I'm sorry for waffling there, but I went with flame graphs. And these look really pretty like a lovely Diwali light there. And just to give you a quick idea of what it is, can anyone tell me what the y-axis represents? If anyone has worked on this? Exactly, so that's a stack frame, excellent. Can anyone tell me what the x-axis means? Absolutely nothing, because it's node. So with that said, another thing, the width of the box you see is the amount of time for which it was on the CPU. And just one thing, so that black box there, that means that that's the process which is running when I took this flame graph. Yeah, so there's a simple controller call here, which is calling two functions, very simple sort of standard design practice. And that looks like this. I'm just getting a post request. There are some middlewares, which I am authentication, authorization, all of that jazz. And then I'm sending it for analysis, which is this lovely function. There are some problems with it. Can someone tell me what they are? Anyone from the crowd? Okay, okay, I'm sorry. So the first object that parts, that's basically a memory leak, because I have a long-term object in a short-term context. And the second one is the classic post and pre-increment operators, which we learn in grade nine, while doing computer science. So JavaScript has this tendency of giving you something called an undefined at where something is out of range, instead of giving an index out of range exception, like the people who use Java, or any other programming language for that matter. So very simply, it is just a plus plus I from zero to 11, I'm going pre-increment, undefined, and there's a memory leak. Now, we didn't really have good debugging practices and monitoring practices, right? And I was having a chat with some of my friends here, and there was a very valid point, which was brought up, that you can do all the logging in the world, but who monitors it, who sees it? Because you need some humanize, right? That's like saying that I have an entire system of CCTV cameras, but anyone can infiltrate if no one is looking. If someone has played Counter-Strike, they'll relate. So how do we monitor it? And the first question is, how do we create those pretty looking Diwali lights I call flame grubs? We can create a heap dump, which is all of the objects in the memory. And then I can just throw it in dev tools and see it from there. Very simple process. You cannot create it in production, though, because it requires twice the amount of memory your system is currently running on. So we had to think with this in mind and how did we do that? So Node has a lovely event attachment function called process.on, where you can attach to native Linux or Nix-based signals. The first one is SigUser2, that is also SigUser1, which are by definition not used by any processes. And then you can just get the heap dump package and you can give this command. Now, if anyone has worked in DevOps or has managed a server writing kill in prod, sounds like no, I'm not going to do that because I like what I'm doing at this company. Let's just go to the man page for this and it says the kill utility sends a signal to the process. The first thing is just terminate or signal a process. So we are signaling a process, not killing it. Please add the dash s. And another thing which you should keep in mind is just restart the process before it locks you out because at one of my companies where we had a memory leak, we were logged out of our production clusters because we weren't able to SSH. The SSH demon wasn't able to, didn't have enough memory to basically decrypt our credentials properly. And for those of you who don't really like using separate packages as I think so happens at large companies, that these two lovely sort of properties on process.memory usage which is a function native in node. I don't remember the compatibility but I think so it is 5.4 above. The RSS or the resident set size is the total memory used by all packages and who can tell me what the heap is? Anyone? Anyone like to take a short like a quick sort of one line description what the heap is? That's the stack, that's different. So the heap is the total memory for all the objects. One thing which I would like to you to know is that heap versus stack, the argument which we have in any other programming language is not the same in JavaScript. For one reason because it is JavaScript. So before we move on, a couple of things here which we should keep in mind while developing applications. Proper memory debugging practices and proper monitoring practices. So you know where your code is not functioning like it is supposed to. The second one is I would say a lovely juxtaposition for who I am as a person, a very talkative gentleman. And I love to log whenever I'm starting an application I just love to write a lot of logs for everything I do. And this gives a lot of response latency as you'll see in just a bit. So I have a very simple route here which just does a status for 200 and sends some JSON response. For any normal engineer, this would be like around three lines of logs. But for someone like me, it is this. Most of it is just for fun. I'm not sure why I do it. The second thing which I want to talk about is who has used Winston here? You've used Winston. Okay, so how do you like it? Good, bad, horrible, very bad. All right. So what Winston does is for those of you who have not used it before, you send it logs and it's going to automatically upload it to your servers, whatever logging server or platform you've configured, which is great. But not for the application. Why? Because you're opening a new socket and as Node.js is a, as they say, a single threaded event based or driven IO system. So it means that if you open a new socket, you're basically compromising your business logic or the amount of memory or space your application has to run on. So the average latency was around 400 milliseconds for something as simple as that, which is literally just stringifying a JSON object. Out of which 328 milliseconds went for just sending it to the production server. So yeah, this is bad, this is bad. Now, in order to refine this process, we need to think about what is the point of logging? The point of logging for a developer at least or an engineer is you get the data, you have the payload, you have the stack. So you can replay everything like it was happening when the application crashed or out on you. Now, why Winston was an overkill for us is because your business logic is not responsible for sending logs to your production server. Simply the amount of complexity involved is just not worth it. And just to summarize all of what I said in the last four minutes is that Winston was really slow. As I said, it is processing these logs through a transport. It is sending it through the transport where it is stored in a database or whatever have you. And application should be responsible for sending them, not processing them. So the better method is write it to STD out. A lovely console at log. Then pipe it to another process, which is again very simple. And you can achieve Nirvana. I'm just kidding, don't try that. With that in mind, the second thing which you should keep in mind is control verbosity. So when I say verbosity, don't keep on waffling like I do for some reason. Just see the amount of logging you need in a separate environment. For example, in testing, you might want everything which is happening in the application. In staging, you would only want the arrows probably because you don't really care about the warnings. I mean, who does? And in production, again, probably the arrows or the fatal exits, something along those lines. So control it. Now, how do you control verbosity in production in real time? So if I see that my 500 arrows are spiking through the roof, how do I change the verbosity so that I can get everything I need to replay the thing which is happening? And this is the question you have that. How will you interface this? How will you make it, how will you bake this into the application such that you can change it right on the go? For that, we use management routes, which are basically, for example, imagine there are two routes, post management log and management health. What I do, I send a simple post request and I just send the parameter there with which I want to change it. Like for example, I want to go from info to trace or from trace to info so on and so forth. And in the health, I can get how my external services are working. For example, how is my postgres database doing? Or how is that lovely Redis cluster going? But this doesn't scale because imagine if you have like a clustered environment with around 40 nodes, how will you go about doing this on every single machine? And the first thing which comes to mind is how can I automate this? Because a good engineer automates anything which takes more than 10 seconds with a shell script. So for that, I will be introducing console. How many of you have heard of at least something called a service mesh or a service framework? Okay, all right, so excellent. So for those of you who do not know what a service mesh is, imagine it to be like a net which interlinks all of every service which is similar or isomorphic in if I had to be really professional at a conference. So what council will do is that it is going to give you something called reactive configurations. Now imagine I have a backend server and I want to deploy 10 bits or 10 instances of that server and I want my front end to use just one DNS because, you know, things can go down. You want like a DNS name-based approach because that is a lot simpler as opposed to going every node by name. The second thing it gives you is as I said reactive configuration. So reactive means that I'll react to something. If someone slaps me, I'm going to react. If someone cracks a joke, I'll probably won't. So that means that whenever the configuration file changes, I will update my application. I am going to reload the configuration file and start from there, which is very simple. Again, we'll be using the process.onNirvana moment for a single signal hang up, sorry, and imagine you have a configuration store like Redux or something. Just reload the configuration there. And there's a very simple code piece I wrote. Of course, don't use this in prod because this is going to give you a memory leak but you get the idea here. Now the benefits of course are multifaceted. You can control whatever you need, whenever you need, you're not wasting a lot of bandwidth on logging and whoever is monitoring for you is probably having a piece of mind because you don't have to look through thousands of lines of logs for a simple request. Now the episode three is probably the last one here which deals with data security and cryptography. Now, I was employed for a project which was written in PHP. Can I get a cheers for PHP here please? As I thought. So it had insecure authentication code. Now what do I mean by that? I mean this. And probably Valakar is going to kill me for showing this to everyone. There's a MD5 happening in a production environment. This is cake PHP for the PHP fans here. Lovely framework. And the bigger problem which I as someone who likes to sort of tell people about things is that most could, you're learning Node, you're learning JavaScript, you Google something, you go online and you see that okay this is the way how you can store passwords, how you can update passwords, how you can create a very simple forgot password flow. They don't cover it properly because that's a huge worry. Think about it. If I can get access to a token with changes in the password, it is as good as having your password. Think about it because then I can change it to whatever I want and instead of probably brute forcing on my GPU. So the usual flow is you get a request, you send a request, send an email, click on the link and magic. The first problem here as I think so, many of us have talked about is predictable tokens. Don't have something which is sequential, one, two, three, four, five, the next token one, two, three, four, five, six is not good, please. They can figure out how they work and they can keep on replaying it for random users. The second one is non-wallet tile tokens which do not expire after use. I have seen this in production applications where I can literally use the same token again and again and again. So I can forge a request basically. So there's a better way. Generate a random string. And how many of you know what HMAC is? So you can imagine it to be like a hash with a password which I can change with the password. Just use a random string and for the key use the current password which you have stored in the database. What's going to happen is that you won't have to delete it because upon a successful reset, the password in the database changes which makes the token by default not valid. Now why did I bring this up? I'm sure most of you can't see what is happening but the first request URL is HTTP and what I'm going to show you next is going to blow your mind that we are transmitting live credentials over a simple HTTP connection. Great, why? Why? And then it is also sending me a cookie which I can store in my system. Let's take a look at that cookie. You can't again see it probably. The user data option looks very interesting here. So I tried to decode it, failed. And this is what it stores. The username and the password, clear as day. So a man in the middle attack is very easy. And my first response to seeing this was this. Right? So just to recap, whatever tutorials you follow online are probably not designed for production so you would want to read about the package of the library you're using while building a system. And with that said, thank you so much for listing me blabber for half an hour on a topic. Any questions from anyone? Yes, I have tried Bcrypt. What did I suggest for encrypting passwords? No, so that was H, that was for resetting passwords. Bcrypt is again, so that's actually a very nice point How many of you know what Bcrypt is? How does it work? Can anyone tell me very quickly? More or less? Yeah, so what it does is that in security there is something called a timing attack. Which means that I can see the amount of time or the amount of processor resource, some process is taken and then I can decrypt it. What Bcrypt does is that it gives you sort of like a way to define the amount of time it takes for the hash to sort of be generated for you. You can control that with something called a cost factor or a costing function. Read about it, it's actually very interesting for those of you who want to use something like Bcrypt. You should also look into argon too, which won the password hashing competition I think so last year. Anything else? Anybody else who has a questions? Anyone in the audience? Yep, thanks Shreyaan. So with that