Understand web development in less than an hour [part 2]

 
The first part of the article explained how a client-side web page works.
Now let's see what happens on the server side.
 

Part II

Server side: forms and databases

 

1. Forms

So far we have only talked about recovering data from the server. What about sending data? Forms are the other side of HTML: they allow us to send information to the server. We may use the forms to update existing information or to add new information. 
The most commonly used methods in HTML forms are GET et POST.
 

 
Take a look at the code above :
We have two input fields (input) where the user can enter data and a submit button (Submit). 
After the user clicks this button, the browser sends the data values ​​entered in the two fields to a PHP script called createproduct.php.
In our example, it's PHP, but it could be JSP, Python, or any other server-side scripting language. The server-side script can read the values ​​sent by the browser via the method POST, then process them or store them in a file or database. In a nutshell, it's how data is sent to the server before being stored.

What is PHP? 

PHP for Hypertext Preprocessor, is a server-side scripting language for creating dynamic web sites and applications. In other words: it is a language which makes it possible to access and read a database then to transcribe its information within an HTML page.
Note: Let's say we want to add validations before sending the data — for example, the product name must contain at least 5 characters, or the “SKU” field must not be empty. We may use JavaScript for these validations. We will then have to react to the click event of the submit button, and check if the web elements have the data we want. If anything is missing, we can display an error message and stop sending data to the server.
 

2. Data base

As soon as the amount of information starts to grow, retrieving it from files can become really complicated as well as very slow. For example, let's take the price list file, suppose the company has thousands of products and we want to know the information of the last product in the list — which means we need to read all the products up to what we find the one we are looking for. This is not an optimal way to retrieve information. It is to solve this problem that the databases were created.
In a database (DB), we store data in tables (a structured set of data). Thus, we can easily perform a search, sort data or perform any other operations.
 

3. Server-side scripting languages ​​& frameworks

We need server-side scripting languages ​​to :

  • store and read information from a database or file;
  • get (GET) information from a server by performing certain operations;
  • read the information sent by the client (POST) and store or distribute them by carrying out certain processing operations.

Typical programming languages ​​such as C and Java can read and write to databases, but they cannot be run directly on the web browser (client). This gave rise to server-side scripting languages.
Server-side scripting languages ​​can do all the usual data processing, communicate with databases, and run on a web server. The most common server-side scripting languages ​​are PHP, Perl, JSP, Ruby on Rails, etc.
Developers started using these languages ​​and they soon realized that they were writing the same boilerplate code for all projects, which led to the development of frameworks that facilitate and accelerate the development of web applications.
Some known frameworks :

  • PHP: Zend, YII, Symfony, CakePHP, Laravel;
  • CMS PHP (also used as frameworks): Drupal, Joomla, SugarCRM, WordPress;
  • Java : J2EE, Hibernate, Struts, Spring;
  • JavaScript : Node.js.

 

 

4. MVC architecture & sessions

The MVC architecture helps us to divide the code into several files and allows us to separate the business logic from the presentation, in order to facilitate their modification later.
Taking the example of a blogging platform, we will come back to all the previously explained topics to see how we can code using the MVC architecture. 
A blogging platform manages dynamic content and could contain several modules such as :

  • Users (users);
  • Items (blog posts);
  • Keywords / tags (Tags);
  • Categories (categories).

Before talking about other features, let's imagine the database design for the table of Articles (tbl_blog_post). Important fields would be :

As you can see, we store duplicate user information: first name (First Name) and last name (Last Name) repeat the contents of the field CreatedBy. If we have 10 blog posts, we will store this duplicate user information in each of the 000 posts. And there could be other information about the user to save, such as their role, their last login date, etc.
The alternative, as you might have already guessed, is to store this user information in another table User (tbl_user) and link it to that of the articles (tbl_blog_post) by an id like below :

This separation of data into multiple tables is one of the many principles of data normalization.
The next important part is to allow the user to insert data into these tables via an HTML form. Remember that we detail these steps to understand the concepts — this is by no means a complete programming tutorial.

Creation of a new blog post by an authenticated user

For this we need an HTML form with two input fields (Title, Content) using which the user can create an article.
Once the user enters the information and clicks the submit button, “Create Article”, the form values ​​are sent to the web server via the method POST. The values ​​sent in POST can be read by any server-side scripting language. The server script (PHP, Ruby on Rails, Python, etc.) reads the value from the form and passes it to the database.
The script can also process information, which can be to retrieve the date and time from the server or to perform certain calculations based on values ​​extracted from another table in the database or from another service. web.
Another point to note: the script can also perform validations, also called server-side validations, to ensure that the data is valid. Only if the data is valid is it saved in the table tbl_blog_post. Otherwise an error message is sent to the client to enter the missing information.
Visually, the form to retrieve data from our table tbl_blog_post might look like WordPress post creation interface :
 

 
There is a field to enter the title (Title), then an input box for the content (Content).
The creation date (Created On), for its part, is retrieved dynamically by the scripting language (here, PHP) and will correspond to the exact moment of creation of the article (year, month, day, hour, minute and even second).
Other data that is not necessary to enter: the identifier of the article (ID). It is generated automatically by the database which ensures that it is unique within the same table.
In our table tbl_blog_post, in addition to title and content, we also have a field called created_by.
How do we get the value to populate this field?

Connected / authenticated user

Generally, most web applications have login functionality. Each time a user successfully authenticates, that user's information is stored in sessions so that information can be reused later.

What is a Session?

HTTP is a stateless protocol, which means that no request GET ou POST sent by the client to the web server is not tracked. If the client (the browser) makes two requests, the web server does not know if they come from the same user. This also means that, for example, if you are connected to an e-commerce site and you add products to your basket, the server does not know that they are for the same user.
In order to overcome this lack of state, clients need to send additional information in each of their requests to retain session information for the duration of multiple requests. This additional information is stored on the client side in cookies, and on the server side in sessions.
A session is an array of variables, in which information is stored in order to be used on several pages. Sessions are identified by a unique ID whose name depends on the language — in PHP it is called “PHP SessionID”. This same session ID must be stored in a cookie on the browser in order to be associated with the user.

Show a single item

The next step is to display the blog posts individually. We need to read the data from the database based on the post id (ID) of the requested article, then display the values ​​of the Title fields (Title) and Content (Content).
Here is the pseudocode to display a single post :

  • Read the database data associated with the item ID.
  • Insert this data into an HTML page containing CSS and JS.

All of the code above can be written in a single file. This is actually how it was done in the beginning, but the development community realized that it wasn't optimal. Indeed, for each new feature to be added, the entire code had to be modified, and it was not easy to work in a multi-developer environment.
This has caused web developers to adopt the MVC architecture, which essentially breaks code into three components :

  • The model : This is business logic, independent of the user interface. In our example, this is the code that retrieves the articles from the database.
  • View : A view a visual representation of the data. In our example, it is the HTML code that displays the articles. So the data comes from the Model, and the HTML is the View.
  • The Controller : It is called at click on the link “See article”. The Controller retrieves data from the database using the Model and displays it in the View.

Let's look at a typical URL for an application using the MVC architecture.
http://www.abc.com/blogpost/id/1
Right here, blogpost is the name of the controller and the view is an action (method) of this controller. id is the item identifier. If we enter this URL in a browser, the request will go to the “View” action of the “BlogPost” controller, and call the model there to get the content of the article with ID “1”, in the form of 'an object. This object is then passed to the “View” to be displayed.
More concretely: the following URL https://www.ux-republic.com/blog/page/2 displays the second page of the list of all UX-Republic blog posts.
Breaking down the URL, we have :

  • blog, the controller
  • page, the identifier that designates the page number
  • 2, the page number


Every time the paging is clicked, it's the same method of the controller blog which is executed and which is responsible for retrieving the content corresponding to the page selected.

Ajax & Single Page Apps (SPA)

If you were born in the last millennium, you must remember the webmail providers Hotmail and Yahoo!, which were very popular in the 1990s and 2000s. When you clicked on the inbox or on an email, the whole page was updated. Around 2004, Gmail arrived with an important feature: Ajax. With Ajax, the whole page is not refreshed — only the parts that need it are. So, if you receive a new email, you simply see it appear at the top of the page, without having to reload it. This helped give users a better browsing experience, and Ajax became a very popular way to build apps.

What is Ajax?

The term Ajax represents a large group of web technologies that can be implemented in an application that communicates with a server in the background, without interfering with the current state of the page.
With Ajax, you send a request by GET to the server, and the server sends its response without blocking the web page, which means that the user can continue browsing without any interruption. The response from the server is inserted or appended to the current web page.
On sites not using Ajax, each user action requires a complete reload of the page from the server. This process is inefficient and creates a bad user experience because all the content on the page disappears before reappearing.
Ajax is one of the techniques used to build single-page applications (Single Page Apps ou SPA's). As the name suggests, the whole app fits on a single page and all of its content is loaded dynamically. JavaScript frameworks like Angular, React, and Backbone.js can be used to do SPA's.

Servers & web browsers

Browsers are the interpreters of the web. They request data from web servers, which process the request and send a response to the browser in HTML (with CSS, JS, images, etc.), and this response is then displayed.
A request to the web server can be made using one of three important methods :

  • GET : get the requested resource as a response;
  • HEAD : same as GET, but the resource is retrieved in the header of the response;
  • POST : send the data to the server.

For example, when you type “google.com” in the browser, the browser sends this command to the google.com server in the background:
GET: http://google.com
The Google web server will then look at its main file (index) and return its response to the client. It usually sends HTML content and CSS files along with any other media files.
 
# Translation of the article Understand Web Development in Less than 1 HourBy Shaik Ismail
 
 
 
 

Audrey Guénée, DEV-FRONT @UX-Republic