Running Javascript Debugger Locally in Serverless Functions

* This is an automated transcript. Please excuse inaccuracies.

‍

Hey everyone, so in this video, I wanted to give you an example of how you can use JavaScript debugger from within your custom functions, alongside with Chrome developer tools and have a really effective way of debugging your custom functions locally.  

Let's jump right into an example. So, before we get going one thing I'd like to mention is that if you're trying to debug functions that are in production, the best way of doing that right now is using the console.log method and just consoling a lot of different arguments objects or whatever you need to the console to see what you are dealing with within the function. However, if you go to Docs.8base.com, you can put a little bit more information about debugging. This document might help you maybe with some more specific questions that you might have while watching this video. However, what we're really going to be going over is the local debugging method which you can start by copying this script to the NPM package of your 8base project that is local on your computer. And then we are going to jump right into it.  

So first off, I'm going to move over to my local project which is right here. And as you can see, I already have the debug script and my package JSON file. So, there's a couple things going on here. First off was that we are running node with the inspect command right or expand inspect flag- thank you- and passing it a path that we are building to the executable within the a base CLI package. So, NPM root - G is going to locate or return the path where your impact NPM package should get global we store it. And then we are building the rest of the path to the ABS CLI executable. And make sure that there's a space after that so that then once we run this command, we can still pass it the commands or the arguments that we're going to be giving to the 8base command line that we are invoking and be able to invoke our functions appropriately.  

For that to work though, we're going to first have to jump over to Chrome and if we go to Chrome://inspect, that will open up this menu where we can then select open dedicated dev tools for node. It's going to launch a window that then will actually capture our process or recognize our debugger, when we run the command with the inspect flag.  

So, having that open let's actually go back to our text editor and look at a really simple function that I put together called “Log Today” where when it's invoked it says the current time and it gets it from this time module which we're not going to look at yet right. So, if I wanted to, I could just copy this command and invoke this locally. And we can see that, oh okay result date time is function, default one something. All right, so it's like returning a function.  

Let's say that we don't really know what this time module is and we'd actually want to jump in and take a look at it, first off what we can do is we're going to add the debugger keyword at this point. So, we go to debugger and we save it and then now using the command that we created earlier the script we use created earlier we're going to say, “NPM run debug” which is that script that we add to our package.JSON file and then pass the rest of the command as we usually would which is, invoke local, log today and the pass to mock file. Let's execute that. We can see that it's listening debugger and it executed, but it didn't trigger. Why? Let's find out.  

I think the reason was is because we have to add a connection or specify connection. Localhost, 9229, let's try to add that one and let's try running that one more time. So, save our file and run- cool, so listening and we got at this time. Alright so as we can see it stopped in our code, however one thing that is kind of odd as if you look at this code it looks nothing like the code that we had written. And the reason is because when we invoke our functions locally, they actually get built and then we are debugging the built code which would be the code that would go into production. So, if I were to go to this hidden folder which is dot build and drill down into the tasks logged today and look at our handler you can see the code that gets generated there right.  

So, there's a couple things to note here that are important. First off is that in here we might see that the import the time module under the name “time”. However, in the console if we were to go in here and say, “Okay you know give me the time”, it would say that, “Hey, this is not here” that's because we're assigning different names for imports requires and sometimes arguments within the function. So, the good best practice on debugging would be that hey if you know that you want to look at what's going on with time, just assign it a Const value. So, let's call it “T = time”. Then as long as your debugger runs after the declared variable while debugging, we be able to use the T variable to reference the module that we wanted to look into.  

So, then if we go back here alright, we can actually do there we can see, hey “time JS.1”. Alright so we see look at here and we see that, oh it's actually a function that got it exported from that time module. If we go there and we say, “time default” and then we execute it we say, “Okay well this is the function we'd have to be executing to get the time back.”  

So, if we go back to our simple function and we update it to where we say, “Hey, time let's get your default function” or maybe we can actually even just do this. One second… no not that. All right, time, default, that way- cool. Let's remove our debugger and let's say detach the debugger- oh one second let's go back to Chrome, go back to sources, exit the debugger that way- cool. Now go back here. Awesome! And now let's just run it and invoke it. Oh, time JS- okay yeah so let's do this. Time and we fixed it.  

So, hopefully this gave you a good idea with a really simple example, of how you can use debugger from within your custom functions while using Chrome dev tools. If you have any questions please add them as comments to this video. Definitely feel free to check out the documentation to learn a little bit more about debugging. However, looking forward to seeing you in future videos.