Refactoring our project to MVC

GetGoing: Introduction to Golang Introduction to API development with Go
8 minutes
Share the link to this page
Copied
  Completed
You need to have access to the item to view this lesson.
This is a free item
$0.00
د.إ0.00
Kz0.00
ARS$0.00
A$0.00
৳0.00
Лв0.00
Bs0.00
B$0.00
P0.00
CA$0.00
CHF 0.00
CLP$0.00
CN¥0.00
COP$0.00
₡0.00
Kč0.00
DKK kr0.00
RD$0.00
DA0.00
E£0.00
ብር0.00
€0.00
FJ$0.00
£0.00
Q0.00
GY$0.00
HK$0.00
L0.00
Ft0.00
₪0.00
₹0.00
ISK kr0.00
¥0.00
KSh0.00
₩0.00
DH0.00
L0.00
ден0.00
MOP$0.00
MX$0.00
RM0.00
N$0.00
₦0.00
C$0.00
NOK kr0.00
रु0.00
NZ$0.00
S/0.00
K0.00
₱0.00
₨0.00
zł0.00
₲0.00
L0.00
QR0.00
SAR0.00
SEK kr0.00
S$0.00
฿0.00
₺0.00
$U0.00
R0.00
ZK0.00
Already have an account? Log In

Transcript

Hi guys. So in the last video we got started with our to do list API. In this video, we're going to be doing a lot of design refactoring, or a code refactoring in order to fit our MVC paradigm. So I'm going to create two, rather three different folders, one is going to be called modal. And I'm going to be having one called the controller. And one having the view or the views.

So when you're talking about web applications, your views contain your static and dynamic templates. But if we're talking about an API, then our views are anything that we send, that our clients can view. So it makes logical sense to have our response structures to go in the views directory. So I'm going to shift it to the views. And what I'm going to do is I'm going to do, I'm going to be going one step ahead and naming it views. So that in main.go, I need to change it, change the data from strux dot response to use dot response and go to So we have our view sorted out.

Now, there is no need for the strux directory, I'm going to be doing away with that. Now I'm going to go, I'm going to go to the model. So model, our model contains all of the routes, because the model link, or my back, sorry, controller, so our controller contains all of the routes. So the routes actually talk between between the views, and the controller. So whatever we are going to be sending out. If you take a look at this, whatever, whatever request comes, we do something with a controller, the request reaches a controller.

And then we build a response or we build a view and then send it out to the user. So control in the controller, we're going to be having one route.go. And our package is going to be called controller. And we're going to be having a startup function which returns a multiplexer. So I'm already screwed up. or other appointed HTTP node.

So mocks so our service is going to be the router that we return. So if you take a look@main.go, here, we are creating a multiplexer. So rather than doing this, what we would have to do is we won't need these functions anymore. We just have to do controller, not startup, rather controller dot register. And then if you go to a router go, we can register all of our routes. So we are creating a new multiplexer.

Over here, we need to do the same thing, but the only difference is that our controller is going to return the multiplexer. And then our main.go is going to be using that multiplexer. So I'm going to do an HTTP dot new serve mux. I'm going to create a distributed the functions and then I'm simply gonna return the mocks So if you go to main.go, our controller was included, we got the multiplexer, or with all of the registered endpoints from our route. And then we, we simply set it up and registered it in the, and also in the lesson. And so, so we're not going to be touching model now, because we're not going to be working with model.

Instead, what we are going to do is, if we keep on adding endpoints in the register function, then this is going to be this is gonna become bulky, real fast. So what we want to do is that let's have all of the routes over here. And you notice that the second argument to the handle funk is a function right? So why not define the function somewhere else? So what we can do is, we can remove this and we can do something like like ping right. So And if we create a new function, a new file called ping.go are the same package.

So what we want to do is we want to create a new function ping which is going to be HTTP dot handler func. So we're simply gonna return our function. Now let's see if this works. Yeah. So don't get confused between handle funk and handler funk. So let's remove everything.

Let's close everything and let's look at only the controller layer. So, controller layer contains a registered function, which creates a new multiplexer and registers the slash ping endpoint with it. And it says okay on slash ping, execute the ping function, and then it returns a multiplexer. Then if you look@ping.go ping returns or handler func so while while when we were being When we are registering endpoints, we do a handle func, when we are registering functions or returning functions each and every function is a handler function. So ping is registered over here it is attached to the slash ping event or the slashing endpoint. And then we are returning the multiplexer, which is in turn, imported by main.go.

So if you start taking a look at this diagram it by paradigm, you can already start to see how clean your code has become. So our main function is just two lines. Our controller register function is three lines, our pink.go is just a simple function in some other fight. So our code readability immediately skyrocketed. So let's see if it doesn't break anything, or if it does break anything or not. So I'm gonna do a quick refresh on it, and nothing so it works like a charm.

Now, one more thing I wanted to talk about was that whenever a request succeeds, then by default we get a status Okay, or a status. 100 from it now how to change that. So I can simply do HTTP dot, right header or rather, W dot right. And in the right header, I can say which response code I want to print. So if you take a look at our API specification over here, whenever we get a check API health endpoint, we return a response code 200. So 200 is same as saying HTTP dot status.

Okay? So one more thing about programming paradigms is it's better to use variables, or it's rare to use constants rather than explicitly defining those variables. So internally constant is okay. It is also our 200. So, let's see what happens if we do look good. So I told you guys that if you do call with a dash IO, the minus sign flag, you can check all other response codes.

So you Far too, let's say those little one. Let's see what happens. Your 201 and 201 means created. But in our case, we need to do a status. Okay, so we're not, we're just gonna roll with that. So summing up all of the programming paradigm, let's look at our entry point.

In our entry point, we are calling the controller dot register, which gives us a registered multiplexer, which we use in our server. So when we go to controller, we register a multiplexer with all of the endpoints, and they're corresponding functions which are defined in different files as handler functions. So we're going to be talking a bit more about this and let's continue this forward in the next video. Thank you guys, and stay tuned.

Sign Up

Share

Share with friends, get 20% off
Invite your friends to LearnDesk learning marketplace. For each purchase they make, you get 20% off (upto $10) on your next purchase.