MVC

I made it to Phase 4! The second to last Phase at Flatiron School! In this Phase we learned Ruby on Rails which is an open source web framework written in the Ruby language. It is a full stack framework allowing developers to build on the front and back end. At Flatiron we were taught JavaScript and React during the first 2 phases so we will only be using Ruby on Rails as a backend language.

Starting this phase made me realize how fast time flies, it feels like I just started Phase 1 a few weeks ago. At the moment I'm writing this blog I have already completed Phase 4 and I'm preparing to start Phase 5. I would say Phase 4 was definitely one of the phases where I learned the most. For project week my group and I decided to make a fake NFT marketplace. Fake meaning we just rendered the jpegs and had a fake cart page. Our main goal for the project was to meet the MVP requirements. While we did do that, we had tremendous trouble connecting the front end to the back and doing authentications. One moment full crud on the project table was working perfectly... then we started working on the front end and errors everywhere! We moved onto doing the login and bam! More bugs! While the project was stressful to do, I'm glad my group and I were able to complete it on time (5 minutes before it was due to be exact!). Now I feel pretty confident moving onto Phase 5 and I'm excited to see what I'll be able to create within the next 4 weeks.

One thing I like about Ruby on Rails was that it wasn't difficult to learn. The syntax was pretty simple and the errors messages were extremely helpful, and less in your face like React. Ruby on Rails has 3 main subdirectories, the model, view and controllers also known as the MVC. These three are the main components that makes up the architectural pattern for this specific software application.

Apeksha Sighn does a great job at explaining how each of these 3 components differ.

"The browser sends a request for a page to the controller on the server
The controller retrieves the data it needs from the model in order to respond to the request
The controller gives the retrieved data to the view
The view is rendered and sent back to the client for the browser to display"

The model, view and controller component all work together to create a functioning back end.

For example, let’s say you’re on a website and we want to add an item to cart. To do that we’ll click on the "add to cart" button and we’ll get redirected to the carts page with our items in the cart. How does one click make all this happen in a matter of seconds?

When we click “add to cart” the browser sends a request to the controller file on the server. The controller files “read” the request and return the appropriate output from the model files. The data retrieved from the controller and model is then passed on to the view. The view renders the data which is what the user sees on the front end.

The view should contain code relating to displaying the data only. The data in this file may be html or a combination of html and ruby code. Everything Ruby sends to the web browser is handled by the view.

The controller holds the functions that defines the routes in the routes file. In the routes file we set back end routes that redirect us every time we make a call. In order for ruby to direct us to the route we have to define a function in the controllers file. The controllers file tells us what information to display when we get to a certain route. This is all then rendered by views.

The models file holds all our table relationships and the validations. The relationships determines how tables can interact with each other and the validations determines if certain functions in the controller will be valid when we run it.

The controller holds the functions that you define in your models file. In the routes file we set back end routes that redirects us every time we make a call. In order for ruby to direct us to the route we have to define a function in the controllers file. The controllers file tells us what information to display when we get to a certain route. This is all then rendered by the views.

Reference -
https://blog1.westagilelabs.com/m-v-c-architecture-of-ruby-on-rails-9712719a69ed