Intro to Backend Logging on Wix Studio

 Alright, welcome to our next video. We are going to be talking today about logging. We're going to be taking a look at various fun ways to log all the things going on with your website and seeing how it all works and how to put it all together along with a lot of great tips. This video is actually kind of an extension of my previous video on backends logging.

So if you're interested in seeing everything that you can do to know how your code is running. The health of it, and if anything needs to be addressed, you can go and check out that video as well. There'll be a link down below.  So, first, I want to just talk a little bit about why we would do logging.

We would do logging for a few different reasons. Number one would be debugging. So, if there's any issues in your code, any errors, Something going wrong that was previously going right. Logs are going to help you determine what went wrong much earlier. If you get, if you catch an error while it's happening, you don't have to go back and trace it down so much later.

So debugging is just a great way to do that. The next one is troubleshooting. So sometimes there are various errors. Errors and performance issues that you yourself notice, and tracking those down as well, is going to benefit significantly from logging. And then the last thing is auditing. Auditing is often overlooked.

Auditing includes things like administrative actions and authorization. So, for example, is there someone repeatedly trying to access something they're not allowed to? If you have sensitive information on your website, and there's certain users who should have access and certain users who shouldn't, You want to make sure that the users who shouldn't not only are not getting access, but if they're trying to get access, then you're aware of it.

And so these are the three main reasons why we would do logging. Also, I want to cover some important tips right here at the start. First is that you need to turn on dev mode or you're not going to be able to see your logging dashboard. So go ahead and do that. You would just go over into your code panel and then you would click the turn on. 

DevMode option on this website, I already have it turned on, but you should know how it works. Number two, I want to cover two different options that you have for logging. You have both out of the box logging provided by Wix, which are called live site logs. These are logs that will appear whenever you have this window open.

If you don't have this window open though, those logs don't appear. Which brings us to the other option for logging, and that is persistent logging. And that can be done via Google Operations and other third party Services where they get sent all your logs from your website and then they record them and from there you can go ahead and search through all those logs and filter them down to figure out what's going on with your website.

Tip number three is don't log too little. So, sometimes we might want to not overwhelm ourselves with data, but I think it's important to err on the side. of logging too much than too little. If you log too little, you won't have the information that you need, but if you log too much, you can always filter it later.

Obviously, you don't need to log every little thing, like I'm actually going to show in this example. But you should be logging everything that is at least somewhat important to you. And then the last thing is tip number four, which is to make sure you show your user's errors still. Sometimes when logging, we'll go ahead, log, and catch an error, and then we won't tell the user about it.

And that's not always a great experience for the user. There's obviously error messages that the user shouldn't be aware of. But it is important that when some, a user is doing something, and it doesn't work out, that you make sure that they're informed about it. That's really, really important and sometimes gets missed when you go ahead and catch an error and send it to your logs. 

So,  let's talk a little bit more about options for logging. Number one, I want to touch on something really quick, but it's very, very common to see people  come into log something and what they'll do is they'll just essentially type console dot log  and then  They'll just say, you know something happened  and that's it.

That's how a lot of people log This is how I log sometimes when I'm coding and this is actually not a great great way to log So there's a few issues with logging just like this  Number one, console. log is not the only log function. We have others as well.  Log is basically the standard, but you want to also log the level of the information that you're logging.

So for example, if you're just logging to share a message that something happened and it's not really important, that should be console. info.  And if you're logging to say, hey, something happened, and it's a little concerning, that should be console. warn. And lastly, if something happened and it's particularly bad, then you would do console.

error. That's kind of saying, like, we have reached an error. Whatever it is, it's irrecoverable in our function, and so it has exited. And These are three of the logging levels. There's a few more, but those I think are, are the biggest ones that you would probably use in examples like this. There's also console dot trace and console dot debug.

So I recommend in your own time going ahead and checking those out. Maybe on Mozilla's developer network, MDN is an excellent resource to go check those out. And importantly, with these error message levels, that also gives your tools later the ability to more clearly visually indicate to you the importance of each of the, the logs that come in.

So for example, if I go to live site logs, what I can see on the right, I can see logs by level and I can see some are errors and some are info. Info ones I know I don't normally need to pay that much attention to unless I'm curious about something. Errors though tell me, oh, something has gone wrong.

Something has gone unexpected and we should go check those out. You even see, for example, in Google Operations you get these nice little icons here and they basically alert you to when there's an error and you can go ahead and filter by severity and a whole bunch of other stuff, but we'll talk about that in a little bit. 

Let's come back over though to our, our error message here because we're not done with it. We're going to just go ahead and change this back to info because  we, this probably isn't something huge. There's obviously no errors happened in this code and we're just typing something out. So the other thing when it comes to logging is, We don't want to just log a string and say, hey, we reached this line in code.

We do that sometimes when debugging, but when you have something deployed and you're running a website that people depend on, you want to log a bit more information. So one of the things that people might do is they might do something like this. They might do, oh, something happened and Oh, I want to tag on this request.

Oh, and then I want to put a  space between it. And then I want to tag on this variable. And I want to record it like that. And so what's going to happen, and I'll put a space here too. What's going to happen is this is going to just get concatenated  into a string.  And when it gets concatenated into a string, it's going to be hard for you to kind of parse and make sense of. 

So instead, what you want to do when logging is you want to  not concatenate into a string like that. Also, you know, you'll see people do the, the fancy string interpolation  where this is, this is actually a much better string interpolation, not to get,  not to get too off topic. But if you just go ahead and, and go like this, you know, you can put, put these inside a string too, but this is also a string.

So this isn't great.  Also, it's more typing than, than I want to do. So really the best way that requires the least amount of typing and gets you the best result is to just put a comma.  And so what we are doing here now is we have a little bit of information kind of on the general gist of what's happening.

And then we are going to log the actual request that the user put in. This is actually very important too. If you have a request from a user, Always log it. These are in HTTP functions, so every one of your functions is going to get a request object. If you get any input from a user though, log it. We'll talk a little bit more about that later.

And so what happens here now is we actually send our string and an object to our logger and that gives us the ability to parse that out a bit better. And yeah, those are the two things that you should definitely keep in mind when, when you're logging.  And so now if we look down here, we see that I've actually done exactly that.

What I've done is I've basically  logged exactly what is happening here, so we're, I'm just saying, hey, we're getting a GET request to, to our function, listCookies. And  we're logging the request and the response that we're sending back to the user. So the entire roundtrip from what the user has sent us to what we're sending back to the user is being sent to our log.

So if anything happens later, we can go ahead and check on it. And this, you know, might not even be the most important thing to log. Maybe we shouldn't even be logging here. That's something for you to consider whenever you're logging. You're writing code, what you're going to log and what you're going to not.

Now let's talk a little bit about what options we have for log reading and storage. So you've seen a couple that I've shown you here. One, the primary, most easy one is your side events. So your side events are live logs, they do not persist. So let's open up another window here for our dashboard. I'll show you how to navigate to it. 

We'll just go ahead, load our regular dashboard,  and come down over here to Developer Tools, and we'll choose Logs.  And you'll see here, we have several options. We have the ability to view our side events, like I just showed you, so let's go ahead and check that out. And you'll see here, since this window wasn't open, there are no logs displayed.

Since this window, which represents the same thing, was open for a little bit, we have some logs that have come in. As new logs come in, they'll appear here, but right now they don't.  Let's head back though, and we'll see we also have Google Operations, which I'll open in a second, and Connect Monitoring Tools.

So this is another way to record your logs. Essentially, you just provide an HTTP endpoint, And whatever service you have outlist sitting there can go ahead and receive those site logs.  And actually, let me grab a link right here from one of Wix's most dedicated and active fellow developers. This is by Quentin.

It is called VLogger, and it's essentially another way to store and analyze and filter all of the logs on your website. So that this tool here actually connects using this. Connect monitoring tools option where there's an HTTP endpoint, it gets sent to that tool. And then that tool you can use to store and then analyze your logs.

So you have a whole bunch of options here. There's other ones as well. There's a whole bunch of third party tools out there. There's also other frameworks you can use. So you could use tools like Winston and Pino. While they won't record logs within Wix's system, they can actually send logs to third parties.

So if you get into really advanced logging, that might be another thing you could do and go ahead and install using our npm package manager. So there's a whole bunch of options out there. But I don't want to overwhelm you with too many options today. There's obviously a lot you can go look at and really for most people, just using your side events, using Google operations, maybe using a third party logging endpoint that you connect through the monitoring tools, which really isn't hard.

I'll just open it really quick.  You just put in the adapter endpoint URL right there that you'll get from your provider, and you click set endpoints and that's it. So it's a super, super quick connection. But these three things really are the things that the majority of people are going to need the majority of the time.

Though it's important to know that there are many, many other options out there as well. And so let's get back to talking about some of the other things to consider when logging and when analyzing your logs. Thanks. So let's first head over to Google Operations and look at some real life logs here. And we'll see that we have, essentially, we have severity, we have the time the log executed, and then we have all the data related to the log.

And so, if we see an error here, we can see, Oh, the current user doesn't have permissions to insert on the cookies collection. That's an error originated by Wix, and a corresponding error originated by our code shortly thereafter. Basically saying that, hey, yeah, this function was called, but there, but it wasn't properly authorized.

And then we get all the details about it. It is a little hard to look through. So you may want to take this message that's in this JSON payload and go ahead and put it into a JSON parser and then you'll get a much nicer structured, structured output. But you can see normally at the end of these that here's the error.

Okay. that the current user does not have permissions to insert cookie, to insert on the cookies collection. Also, when you're looking at your errors if you encounter anything that you think is not an issue in your code and maybe something happened on the Wix end and you would like us to look into it, You can always reach out to customer support, and this is why it's so important to log enough data so that you have it for later because it will make everybody's life easier is the Wix request ID.

These will definitely come through whenever you're doing HTTP functions at the very least. And you can go ahead and pull those out and provide those to support staff because they'll be able to take that number and very quickly identify the exact request. that had the issue and drilled down much further and quicker there.

I'm not saying that they'll be able to instantly pinpoint the issue, but it really helps streamline the debugging process. And while I don't want to take you through everything that has to do with Google Operations because this is a Wix Logging video, not a Google Operations video, it's also important to know that you can go ahead and filter your logs.

Like I mentioned earlier, it's better to log too much than too little because you can go ahead and filter later. Obviously don't overwhelm yourself, but error towards too much. So up here, you have the ability to search all fields. And you can filter by severity too, so if you only wanted to see, for example, errors and higher. 

You can go ahead, filter on that. And then if you wanted to drill down further and say, Oh, I only care about things that are invalid insert. I can go and filter there. And we see that, oh, I'm only seeing the errors related to invalid insert. And that's just some of what you can do here. You can do a lot, lot more.

Google Cloud Operations and Google in general has a ton of great docs, so go ahead and check those out in your own time. And now let's do a quick recap and final takeaway tips from this video. So, first, I would say always use machine readable structured data wherever possible. Don't just record strings.

Strings are useful. They can give you extra contextual information. But make sure whenever possible record objects as well. And that's very easy in any of these. info. log. debug. It's just providing it as an extra argument. And number two, make sure to log too much rather than too little. If you log this and you only log this part, or maybe you only included the response.

Then you wouldn't get the request ID that we mentioned before that is very useful for helping Wix staff track down issues if you encounter anything that you think you need to reach out to support for.  And number three, avoid logging sensitive information. Do not do it. Do not log emails. Do not log passwords. 

Logs are stored in plain text and that is an inappropriate place to be storing anything sensitive to your users. If you need to store what user tried to do something, Then store their member ID stored their slug of their username. But do not, do not store their emails, do not store their passwords, do not store their addresses or anything else in your logs.

And lastly, this is a bonus one for those who stuck around until the end. There is another set of functions that the console object provides which are super, super useful for when you're evaluating performance issues in your project. Obviously, you want to catch these early, but sometimes you encounter performance issues that are transient.

And So you might have a function that in your testing, and 90 percent of the time for users, executes in one second. Everybody gets a quick response and everybody's happy. But there might be 10 percent of the time where functions, for some reason, that you haven't figured out yet, are taking 10 seconds.

And this is taking too long, and it's causing delays, and a poor user experience. These are called console. time and console. timeend. So, if you ever needed to log how long it took your function to execute, you could call console. time, give it a label that's useful to you. So, for example, we'll call this one list cookies. 

And it will start a timer here, and then we'll want to end the timer, you know, in this case, right before our return statement, we'll do console. time. end, and provide it the same label,  and that will end that timer. And so then you can go ahead and deploy that, wait a little bit until you get some requests that come in, and then you can go and drill down into those requests that are taking too long.

And yeah, so that's it. Hopefully you've learned a good bit about how logging works on Wix. How to do everything. If you have any questions, we always have the forum that you can reach out on, on forum. wixstudio. com. We have our Discord,  discord. gg slash devs on Wix.  And we have a whole bunch of resources out there too, so, you know, you can always Google whatever questions you have when it comes to Wix, when it comes to logging, or to anything else.

Thank you very much for watching this video, and hope to see you again soon next time. Bye!