Logging & Watching for Changes

[00:00:00]
>> Now, something important, that is going to be something you need to get used to in case this is the first time you're creating a web server with a system like this. What happens if I, for example, add a clinician mark, so a couple of exclamation mark, I save, I refresh?

[00:00:19]
And I'm not getting those exclamation mark, why?
>> Restart. I need to restart the server because the server was compiled and is in memories being executed. So I need to stop the server, CTRL C and run it again, and then refresh the page. We have a question in the chat.

[00:00:37]
>> How do we enable debugging in Go HTTP to write requests, response, or counsel, or logging?
>> Okay, so to enable debugging, actually, it works the same. It doesn't matter if it's HTTP or not. If you're using VS Code, you can enable debugging, for example by setting a breakpoint that's one way.

[00:00:58]
And then you can go to the debug menu that you have here and you can run and debug. If you click run and debug, it will start your app but now in debugging mode and you have all the tools that you used to have when you are working with Go.

[00:01:15]
Have in mind you have to do more with VS code. So, if you need to be in the main.go file, if you're in a different file, the debugger will try to run that file, and that file has no entry point, okay. So, if you have that situation, you need to create a launch.json file.

[00:01:35]
That's something not from Go but from VS code. It's a configuration file where you can say to VS Code, hey, VS Code, I want to always run the main. So start with the main. It doesn't matter where I am, where I'm putting the breakpoints. I need you to start from the main.

[00:01:52]
And if then you go to the browser, you refresh. If it gets a breakpoint, you will stop and you will be able to debug. Okay, so you can see it's pretty simple how you create a server. I mean you can create little functions like this but most of the time, we create functions outside or even in a different package.

[00:02:20]
So I'm going to move that function outside, when I move the function to the outside in I need to set a name for the function, so let's call that HandleHello, and then I need to remove the parenthesis now and I will pass, HandleHello as the second argument. Be very careful here.

[00:02:41]
Handlehello, has no codes. I'm not executing the function. I'm passing the function as an argument. That's possible in Go. So if you have a function, you can pass a function as an argument. In this case, you are passing the function to the HTTP default handler. Okay, makes sense?

[00:03:04]
In this case, you can see we are handling directly over the HTTP package. It's kind of a global server, right? So it's me, it's weird the first time you see that I know creating a server I'm just like, defining handlers for the whole package, which forms a lot of pressure, is okay, but technically, because you can open go routines.

[00:03:29]
You could have more than one web server running at the same time in different go routines, not in the same one because it's complicated when you're listen for one, you cannot execute more code. So after this line you are there waiting. So I cannot open another one in the next line because it will never be executed.

[00:03:49]
Does that make sense? But I know I can use go routines. Well, in that case right now, I'm actually adding handlers to some kind of a global scope. I can change that, and for that is the second needle that I didn't even explain what that was. It was called the handler.

[00:04:06]
So instead of working globally, I can actually create something that makes things simpler. So I can create an object, so I can call this a server. And the object, it's known as a ServMux. It's a multiplexer. So for that, we use a factory. Do you remember what a factory is?

[00:04:29]
It's just a function starting with the name new. So it's a new. We have a NewServMux, like that. And now we are going to instead of add the hunter to the http, we're going to add the handler to server. And then instead of nil, add the second argument, we're going to pass that server option.

[00:04:51]
It's working in the same way. We haven't changed anything more than now. It's better coding. So we are adding the handlers to one special server, and then we can have another one with other handlers. Does it make sense? It's the same, it will work the same. If I stop and run again, it's still working.

[00:05:10]
By the way, this thing of stopping and running seems like a lot of work, okay. Is Go giving me any other solution, actually, no. We don't have any other solution from go, okay? So you need to stop because why? Because go is building. So if you make a change, we need to make a new bill.

[00:05:31]
So all the tools that are available are not from go, are from the community or even from other solutions, you can use things like nodemon that is from node.js. So if you search nodemon for Go, you will find here you have five waves to live reload your Go applications, okay.

[00:05:49]
But this is not from Go. So these tools are actually detecting your file system. And when there is a new.go file or something you have changed, it's stopping. The server and running the server again, okay? But it's a manual thing, but with a tool. There is one, for example, it's pretty old.

[00:06:08]
It's one of the first one that is called gene. And if you are thinking on a gene framework, that's not the one you will see what, we'll, see what that is in a minute and why it's called, but this is not that one. It's this one library, low utility for a Go, okay.

[00:06:26]
It's a simple command-line utility for live reloading Go web applications. You install it and then instead of using run, you use gin run, and gin is like a listener instead of server that is observing the file system and every time you change it, it will stop the execution, and build it and run it again, okay?

[00:06:46]
We don't need to use them for today. But have in mind that you need to find a solution to that on your own. Okay, something similar happens on node.js. Cool, well, what's next? Typically, the next step is to serve a folder, like for example, I could have a public folder here.

[00:07:12]
Isn't that that every folder is a package? No, actually no. If you don't have Go files inside, it's not a package. How do you know, you don't know it's your organization. So if you have folders, without go files, it's not the package. In fact, the compiler will just ignore that completely.

[00:07:32]
So it's not like every folder will must be a go bucket, no. And here we can actually add files. Yeah, and I can create an index HTML, images and we can try to serve that. I already have, we are not going to waste time writing HTML code. So I already have a website ready to serve that is actually here.

[00:07:57]
If you go to github.com/ for my first man my last name/go fundamentals, you have the front and master museum there is also a there's a zip file, so if you want very quickly you can download the zip file It's just HTML, CSS ready to serve. Okay, so you go there, you can download the file.

[00:08:24]
I have them here already available. Go to Go, femmuseum, public. They will just get those files into my public folder. I will replace my index.html. And for that it doesn't matter what it does, but you will see it in action in a minute. It's a website. If you're doing a back end, you don't care about the front end.

[00:08:52]
So you just do I know, someone is giving me a public folder, I just need to serve that folder, that's our own responsibility.