Laying the foundations

So in this episode, we will be laying the foundations of the application architecture that we are going to be using to build this block.

We will talk about what ModelView or MSE is, how we can adapt it to go, and we will also scaffold the base project folders.

This is simply a way to define ModelView's controllers at a high level and connect it to another important concept, the separation of concerns.

MSE is an architectural pattern that can be done in a lot of different ways.

We are just going to be having these three packages, ModelView and Controller.

You could also do this on a resource base, so you would have a user package.

I think that is probably overdoing it when starting out, so we are just going to have very clear separations of what is a model, what is a view, and what is a controller.

So these three components at a glance, we have models that is simply data plus business logic.

This is the only layer that we will have any interaction with the database, so fetching it.

Storing it, creating it, updating it, all of this has to go through the ModelLayer.

Then we have the ViewLayer, and here we will in this course do HTML based views.

You could adapt this to also do JSON views in a sense, because the only real thing here is that the view is just the outwards representation of whatever is returned from the server.

So you could also have a defined views for your APIs in here.

You could also have a defined views for your APIs in here.

Finally, we have the ControllerLayer that is simply a way to coordinate requests between models and views.

So in a very basic form, we will just have our quest come in.

If it has some data, we will grab that data, send it to a model, and then return a response through the views based on whatever the model returns us.

You can also extend this with services or background jobs.

There's a lot of options here, but we will just have this.

We pass it, we chug it into the ModelLayer that then returns a response, and then based on that response, we will render a specific view.

Right, so models here defines the core domain pieces.

So for our use case here, think of a user or an article or a newsletter.

This is how we control how data is accessed, manipulated, and encapsulated in business.

logic. The view layer are about presentation and they can return HTML, JSON or any other format.

We try to keep them as dumb as possible. They should simply render what they are giving

in most of the cases. We could have some logic depending on let's say if the user if you have

a user that's logged in we might show something to them but it's based on what we provide them

from the controller layer and the controller or controllers are simply the glue. They accept

the request, they invoke some models and then they hand off the response to the view layer

and a mental model for these is a traffic control. They orchestrate request response flows.

So why does MuC help and why is a really good pattern to start with? Well it emphasizes the

independence of layers.

Teams can work in parallel if you get to that point. Refactors can be localized and predictable.

Redesigning the UI should not require changing any of the business rules

but we can have the business rules drive a change to the UI.

It's predictable, it's testable and it's also a lot easier to maintain for for a long

a long period of time.

We also have some things that we don't want to do.

Some critiques of a classic model view controller which is that it's very importance heavy

and it that doesn't map one-to-one in Go which is or is okay. Our goal here is separation

of concerns. We are not trying to mimic what you would see in object-oriented languages like Rails

or Django. In practice MuC works really great in Go when we learn to lean into the the strengths of

Go. So interfaces, packages and small composable units.

Hopefully you will see when we get through through the course that that just applying the

overarching concept of MuC to Go is actually pretty straightforward and maps really well

for how Go works. We don't need this object-oriented approach to actually do MuC

in Go and I also mentioned here the full name and the pattern boundary sorry the pattern boundaries

are. So we should just think of what is a model on a conceptual level what is a view on a conceptual

level and not as much as the names we are giving to them. So that's what I said in the beginning.

You can have let's say a user folder that has all the logic so it's more of what goes into the layers

or what goes into the certain file. So we always do data in a model layer and we always do views

in a view layer and not necessarily where they are in the in the folder or overarching folder

structure right. So we are going to be following the idea of MuC which is clear responsibilities.

We are going to be using interfaces and packages instead of inheritance and we're going to keep the

layers clean explicit and composable. So just in a second we will be scaffolding the base structure

of the project. We will be creating all of these folders so we have a base to work from in the

upcoming episode. We want to have something that looks like this where we have the main

entry point in command app. We have the main business logic and models. We have template

response rendering in views. We have request ending and orchestration in a controller folder and we'd also need

some route and some routes so we can register a route with our controller and easily reference

it throughout the application and we also need a config so we can have some what is known as

env variables that would be our secret so we can access the database or access third-party services.

So to begin we are going to initialize a go module so say go mod init bleeding edge block which then

created this go.mod file here then we will create the model view controller folder so

on linux this is mkdir models views controllers then we're going to create our command directory

where we will create an app folder as well then we will create router and routes and finally we

will create config.

So if we jump in now we have a bunch of folders with nothing in them yet but this is the folder

structure that we are we have or we the base folder structure we're going to be working with

in the course. We will be adding to them over the next episode so we have a more complete

base to work from when we actually start building the block but this is where we are going to start

and all of these will hopefully make make more sense once we have been through this

this next upcoming episodes and modules so to recap

model view controllers give you some clarity about what goes where and also how to mentally think

about certain layers of your code it's scalable we will adapt this to fit go strings and then we have

basically we are basically ready to start tackling real world projects so in the in

the next episode we will dive into models and we'll start shaping the domain