Lesson Weekend

In the coming lessons, you'll start to learn how to build applications that run on a web server. These applications will receive HTTP requests and return HTTP responses. Regardless of whether you are learning Ruby/Rails or C#/.NET, you'll use some sort of pre-built web framework to receive an HTTP request, define what code to run, and return an HTTP response.

Examples of popular web frameworks include Ruby on Rails and ASP.NET, which we teach at Epicodus.

All web frameworks perform the same basic tasks:

  • receive an HTTP request;
  • based on the request's path and HTTP method, figure out what code to execute
  • generate HTML, CSS, JavaScript, images, and any other relevant assets
  • return an HTTP response to the client

Web framework

The most confusing part to new programmers is the second step: using the request's path and method to figure out what code to execute. For example, if a client makes a GET request to /kittens, one set of code will be executed. If the client makes a POST request to /kittens, a different set of code will be executed. If the client makes a POST request to /puppies, yet another set of code will be executed.

This is very different from what we learned in JavaScript. But remember, we were building client-side applications in JavaScript. These applications run entirely in the browser. Webpack bundles the code and stores that bundle in the browser — so whenever a user does something, the code is already in their browser.

Now, though, we will be building server-side applications. When a user does something, a request will be made to a server. The server will execute any necessary code (as we described above) and then return a response to the user.

This approach has its advantages and disadvantages — obviously, the user experience will be much more seamless if the code is already stored in the browser. Communication to and from a server takes time. However, there are many things that must be done server-side. For instance, servers store large databases — there's no way that content could be stored in a user's browser. We'll be working with databases in a few sections.

MVC Pattern


One common way of organizing code in a server-side web framework is called Model-View-Controller, or MVC. The program's core logic is written in its models. The user interface is coded in views. And the controllers handle web requests, figuring out what model code to run and which views to return back in the HTTP response.

For example, if we had a web application where a user could translate a word from English to pig latin, the actual translation code would live in a model. The HTML for the web pages to submit a word and to see its result would live in the views. Finally. the controller would be responsible for figuring if the user had requested to see the page to enter an English word, or had submitted the form to find out what its translation would be.

Don't worry about the MVC pattern yet, though — we'll learn more about it when we start working with Rails in a few sections. For now, we will be using a much lighter framework called Sinatra which doesn't use the MVC pattern. However, Sinatra is a server-side framework — and it's a great tool to learn the ins and outs of the HTTP request-response cycle.

Terminology


  • Web framework: Software that manages the necessary code for handling HTTP requests and responses

  • Asset: External file used to build the user interface of a web application; can be JavaScript files, images, CSS.

  • Model-View-Controller (MVC): An organization pattern in server-side frameworks that groups together core logic into models, user interface logic into views and the code to manage the HTTP requests, application code to run and HTTP responses in controllers.

Lesson 2 of 37
Last updated August 7, 2022