I can't believe I'm in week 5 of Fullstack already. It's sort of absurd how quickly this whole thing has gone by. Originally, I had grand ideas of writing posts once a week, trying to discuss at least one thing I learned, but every time a start a post, I end up leaving an illegible draft while I get sucked into the next big topic. When I do finally come back to my drafts, I can hardly remember why I found a previous topic interesting enough to write about. Perhaps it is the nature of understanding something, that the truly interesting things are the ones we don't understand.
But one topic which I'm still feeling jazzed to write about even a few weeks later is MVC web apps. Probably because I'm still trying to understand this whole Model View Controller thing in all of its beauty. I had previously made a MVC web app before my time at fullstack, but it was firmly rooted in the "magic" category of my brain.
When I call something magical I generally mean both of the following:
1. That I think some amount of code allows me to do something desirable.
2. And that I only have fuzzy ideas of how that code actually works.
I think it's a common experience for new programmers to tackle a tutorial like a blog building application after a few experiences with code school, and codecademy. They're tempting to launch yourself into before you really "get" stuff because you get to make an actual thing that can be locally hosted on your own computer, rather than playing with pretend programs within a browser console.
You also get to experience more of the Full Stack. You'll have a front-end and a back-end (even if both of those ends are mostly copy and pasted). And you--yes you!--get to put it together. To make this possible, (and within a reasonable time frame for a beginner project) you'll probably use some sort of scaffolding to get you there. But of course there in lies the rub. Often this means typing lots of things into your command line (another new-ish skill for many), where files are generated and you don't know why or how. If you've never encountered the structure of a simple (but full stack) web app before, there's a lot of magic in that scaffolding. And if you don't understand the scaffolding, then you probably won't understand how you're piecing together your front-end and back end. So while those tutorials are awesome for making a thing, if you don't actually learn what all of those randomly generated folders are for, or what your middleware helps you with, then you'll have to forget about even attempting to recreate that magic without the tutorial.
To help you avoid falling into that pit of despair, I'd like to take a moment to talk about how a simple web app could work, which will hopefully help you get through your first blog making tutorial. The following is my attempt to de-magic-fy some of that scaffolding, and speak generally about what I think are the major concepts you'll need to know when tackling your first MVC web app.
(Please excuse my poor artistic ability. But I think it's more helpful than not, so I'm keeping it)
Step 1. What happens when you go to any website through your browser?
Well, it may not seem like it, but your browser is actually going to a specific IP address where some computer somewhere is hosting your web app on their server. In the case of your first web app, you're hosting it yourself. What happens when you land on that server? Let's take a pretend blog example. Maybe you want your client to see a list of blog post titles when they arrive on your URL(http://myawesomemvcwebapp.com). How would you go about that?
In your Controller you might have a route for a GET request, which will find various pieces of data, render them properly and eventually send them back to you. Your controller doesn't store those blog posts, and it doesn't store how you display them, it is only in charge of hosting that server, organizing your various routes (think of routes as different url pages), and telling your program to fetch things (like your blog posts) and how to display them.
TLDR: Your controller sets up your server, it organizes your routes (aka urls/pages) which will fetch certain data from your database, and then your controller dictates which html files to look at to then render that data in a more readable way for your client.
Step 2: Where does it fetch that data from?
From the model! Your model might just be a bunch of hard coded files with your blog posts stored there. Or your model might involve some sweet middleware that lets you store all of your vital information (blog posts, passwords, whatever) inside a database on your computer (or elsewhere). Middleware may seem like a vague term, and that's because it is. Middleware is really just a fancy term for some pre-written code that makes your life a lot easier during almost any step in this process. You could write it yourself, but it will take a long time. Instead in whatever tutorial you pick up, you'll probably end up installing lots of random things that you are only vaguely aware of what they do. I think it is ok to remain somewhat vague on middleware at first, but it is definitely worth going back later and looking at the documentation to figure out exactly what each piece does. Some examples of middleware that I've used have been express, which I use to control my server and my routes, mongoose, which allows me to make requests of my database easily, and swig, which allows me to embed javascript directly into my html files (coming up next) with ease.
TLDR: your model finds all of your secret important information and sends it back to the controller for...
Ok so maybe you've successfully gotten the raw data, but how will the browser know where and how to display that data? That's why you have a controller! It will suggest that you render your information through a specific html file in a Views directory. Often you'll have one or more html templates hanging out in the views file.
TLDR: Your views help you display/render your data to the client
Things can get more complicated at any point in this process, and I am deliberately trying to keep this simple. But I think it's an important point to add that from here on out if you want your client (aka anyone looking at your site from through a browser) to see something (maybe styling, animations, etc), it has to be made accessible. For good reason, your full database and all of your folders will not be accessible generally to your client. When you set up your controller and routes, you specified under what scenarios you want to show information from your database, and how you want to render it. So if you want to have other things (maybe stylesheets, or jquery or something) visible for your client, you'll have to specify that in your controller. Since that material is not dynamic (meaning your styling sheets will stay the same throughout your application), it's often referred to as being "static". If you have a "public" folder generated through your scaffolding, it is likely that there is an additional call made in your controller which specifies that for any additional static information, go directly into the public folder.
TLDR: public folders contain public static info, aka things that don't change (stylesheets, jquery, images, etc).
Hopefully if everything is linked up properly now your homepage (or whatever routes you have created) will display when a client visits your site! Each time you click to a different place or type a different url in your browser, it will repeat the process with a different GET (or post or put or whatever) request, again going through your models, and views, and guided by your controller.
Hopefully this brief overview will provide a nice introduction to your first attempt at a fullstack web application. I would definitely recommend going through a tutorial or two of some kind, but hopefully this brief walk through might help to reveal some clues as to what your own particular scaffolding is doing (if you use it at all), and how all the pieces fit together.
