Web Applications

This chapter lays the groundwork for understanding the pivotal role web applications play in our fast-evolving digital world. This chapter highlights their significance and the need to grasp their core concepts for effective participation in today’s interconnected landscape.

Key Points

• Web Application Fundamentals:
  • Web applications are software accessed via a web browser, requiring a server for hosting and transaction handling.
  • They serve diverse purposes, from e-commerce to social media.
• Client-Server Architecture:
  • A model where clients request services from a central server.
  • Three-tier architecture separates presentation, application logic, and data tiers for enhanced scalability and performance.
• Modern Web App Architecture:
  • Consists of frontend (client-side) and backend (server-side) components.
  • Frontend: Uses HTML, CSS, and JavaScript for user interface and interactivity.
  • Backend: Handles business logic, data processing, and database interactions.
• Frontend Technologies:
  • HTML: Structures content.
  • CSS: Styles content.
  • JavaScript: Enables interactivity and dynamic features.
  • JavaScript frameworks such as React, Angular, and Vue.js enhance development efficiency.
• Backend Architecture:
  • Layered architecture including model, controller, service, and persistence layers.
  • Handles user requests, business logic, and database interactions.
• REST (REpresentational State Transfer):
  • An architectural style for creating scalable and maintainable web services.
  • Utilizes HTTP methods (GET, POST, PUT, DELETE) for resource manipulation.
  • RESTful design decouples frontend and backend development.
  • Guiding principles include client-server, statelessness, cacheability, uniform interface, layered system, and code on demand (optional).
• REST Requests and Responses:
  • Requests: Include endpoint, method, headers, parameters, and data body.
  • Responses: Deliver data (JSON, XML) or status codes.
  • Postman is a tool used to test REST API's.

Sources and related content

Why Web Application?

In today's rapidly evolving world of information technology, web applications have emerged as an essential component of our digital landscape. These applications are at the heart of our online experiences, enabling us to access and interact with a wide range of services, from social media platforms to e-commerce websites and productivity tools.

Having a basic understanding of web application concepts is crucial for individuals and businesses alike. It allows us to navigate and harness the power of the digital realm, empowering us to communicate, collaborate, and conduct transactions more efficiently.

Furthermore, as web applications continue to shape various industries and sectors, possessing knowledge about their concepts ensures individuals can adapt and innovate in this digital era.

Whether it's understanding the fundamentals of client-server architecture, grasping key web development technologies, or comprehending security considerations, a basic understanding of web applications equips us with the necessary skills to fully participate in today's interconnected world.

What is a Web Application?

An application can be considered as a complex piece of software, which consists of many different components.

Web apps can be designed for a wide range of use cases. For example, an E-Commerce Web App will have such components as user registration, product display, login management, product management, user checkout etc.

Web apps are usually accessed through a network with a web browser such as Google Chrome, Mozilla Firefox, Safari etc.

For a web app to operate, it needs a server which hosts the web app and handles the transactions between browser and the app.

Client Server Architecture

Client Server Architecture is a computing model where the server hosts, delivers and manages most of the resources and services to be consumed by the client. One or more client computers will connect to a central server over a network or internet connection.

In this case, the server is always running and waiting for requests to come. Clients are often situated at workstation or personal computer, while servers are located remote on the network, such as in an on-premise data center or on the cloud. For clients to communicate with the server, the former usually sends out a request to the server, once the server receives the request, finished processing it, a response will be sent back to the client.

Three-tier Client Server Architecture

The 3-tier architecture is extended from the basic client server architecture.

A three-tier client/server is a type of multi-tier computing architecture in which an entire application is distributed across three different computing layers or tiers. It divides the presentation, application logic and data processing layers across client and server devices.

• Presentation tier – the frontend layer and consists of user interface
• Application tier – contains the functional business logic which drives an application’s core capabilities
• Data tier – comprises of database/data-storage system and data access

There are many benefits to using a 3-layer architecture including speed of development, scalability, performance, and availability.

Modern Web App Architecture

Web app development has experienced several stages in the history, from tightly coupled monolithic development to lately REST-based architecture.

Here is a general architecture diagram for a web app.

Taking an E-commerce web app as an example.

A user opens a browser from his laptop and he types a URL to access a web app. The browser connects to the frontend server of the web app through HTTP and displays the content in it. The content here can be roughly divided into two parts: Graphics and Data.

The graphical part is rendered by your browser based on the content served from the frontend server. The data part is not served by the frontend directly; instead, it will communicate with the backend to fetch the proper data. Meanwhile, the backend server may or may not have that data handy. If not, it will need to communicate with the database to fetch the data and pass back to the frontend, which will again send to your browser. Based on the graphics and data the browser gets, it renders them and displays them as what you see day-to-day.

Let’s take a look at some more details on each part.

Frontend

Frontend developer uses three primary coding languages to code web apps:

• HTML
• CSS
• JavaScript

The code written will be running inside a browser, this is in contrast to a backend developer, whose code runs on a server.

Modern frontend development will leverage frameworks like Angular, ReactJS etc. Yet, no matter what fancy framework is used, eventually the code will be built into HTML, CSS and JavaScript or a part of the three, as those are the only elements that can run in a browser. A JavaScript framework cannot run directly in a browser.

HTML & CSS

HTML (Hyper Text Markup Language) gives content structure and meaning by defining content as, for example, headings, paragraphs, or images.

CSS (Cascading Style Sheet) is a presentation language created to style the appearance of content using such elements as fonts, colors, etc.

Technically speaking, HTML and CSS are actually not programming languages. In a broad sense, a programming language is a notation for writing programs, which are specifications of a computation or algorithm. HTML & CSS are not “executed” by computer; rather, they are parsed by an engine from the browser.

JavaScript

JavaScript is a programming language that allows you to implement complex features on web page. Without JavaScript, a web page will just sit there and display static content information for you to look at.

This is YouTube in 2005.

Why is it called JavaScript?

When JavaScript was created, Java was very popular, so it was decided to name after Java. But as it evolved, JavaScript became a fully independent language with its own specification called ECMAScript, which has no relation to Java now.

How JavaScript Works

First, let’s understand how browsers work with HTML and CSS.

A web browser loads a web page, parses the HTML content sent by the Frontend server and creates something called Document Object Model (DOM) from those HTML contents. This DOM allows the web content to interact with your JavaScript code.

Also, the browser will grab everything linked to the HTML, such as images and CSS files and then send them to CSS Parser which will then update DOM content.

HTML and CSS are put together by DOM to create the web page first. After that, the browser’s JavaScript engine loads JavaScript code and executes in the order the code is written. Executing JavaScript code after HTML and CSS finish loading is important and developers usually write code to enforce that.

JavaScript Framework

Framework is not a must for development but they are more adaptable and flexible for the designing of web apps, so most developers prefer to use it.

A JavaScript Framework differs from a JavaScript library in its control flow: A library offers functions to be called by its parent code, whereas a framework defines the entire application design.

Some of the most popular JavaScript frameworks are:

• Angular
• React
• Vue.js
• Ember.js
• Meteor

Backend

Backend provides services based on business logic and workflows.

The backend architecture could be very complicated sometimes. From a web app perspective, backend can be considered as a layered architecture like below.

Model Layer

You’ve probably heard about the MVC (Model, View and Controller) pattern. It is one of the most frequently used industry-standard specific development aspects of an application. Basically, it’s an architectural pattern that separates an application into three main logical components, each of which are built to handle specific development aspects of an application.

The Model layer can be related to the M in MVC pattern.

• Model – corresponds to all the data-related logic. This can represent the data that is being transferred across other layers or any other business logic-related data.

Controller Layer

Controllers can be considered the uppermost layer of a web application. It is responsible for processing the user's input and returning the correct response back to the user.

Service Layer

Service layer resides below the controller layer. It acts as a transaction boundary and contains both application and infrastructure services.

Persistence Layer

Persistent layer is the lowest layer of a web application. First of all, data cannot just sit in the application. They need to be saved somewhere so that you don’t lose them when something bad happens with your application. Furthermore, application resources are limited and they are mainly used for processing and data should be stored elsewhere, mainly in a database. The persistent layer is responsible for communicating with data storage.

An Example Workflow

To better understand how the backend works, let’s take a look at a user login scenario. User starts by typing a web app URL into the browser, and the app home page prompts the user to login.

Steps:

1. A user accesses a login page of a web app
2. Frontend server returns the page content to the user browser
3. User inputs user name and password and clicks submit button
4. Frontend passes username and password information to controller at backend
5. Controller send username and password to corresponding authentication handling services
6. User inputted password needs to be compared to the existing password, so service requests persistence layer to retrieve the user’s password
7. Persistence layer component sends a query to database
8. Database returns the password to persistence layer component
9. Persistent layer sends password back to the service with the original request
10. After the service compares the user inputted password with the existing password, some additional logic process will happen. Then, the service sends back a result, say, the user is authenticated.
11. Controller sends back the landing page info after a successful user login
12. Frontend server sends back the landing page content to user browser and browser display the landing page information

Of course, this is a relatively high-level workflow and a lot of details are not mentioned here. The point here is to show how a backend works in general.

REST (REpresentational State Transfer) Protocol

Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating web services.

REST is used to build web services that are lightweight, maintainable, and scalable in nature. A service built on REST architecture is called a RESTful service. The pre-assumed underlying protocol for REST is HTTP, as it fits the REST spec well.

Advantages of REST for Development

RESTful design decouples frontend from backend and this has plenty of advantages in terms of development and maintenance. Some of them are:

1. Separation between the client and the server. This lets developers treat Frontend development and backend development as two separate parts. For example, the frontend team can use different frameworks to suit their needs as long as they communicate with the backend through REST.
2. Scalability. As client and servers are separated, we can have the product scaled without much of the difficulty, compared to when client and servers are tightly coupled.
3. Independent of Platform or languages. Since REST leverages HTTP, you can use different kinds of languages, PHP, Java, Python or Node.js as your backend development tool. This gives you a lot of freedom on the backend development.

Relationship Between REST and HTTP

In simple words, HTTP is an application protocol while REST is a set of rules that enable you to build an application that has a specific set of desirable constraints.

The reason we use HTTP as a means for RESTful communication is that the infrastructure, servers and client libraries for HTTP are widely available and HTTP as a protocol fits the rules of REST very well.

Guiding Principles of REST

REST has its own 6 guiding constraints which must be satisfied if an interface needs to be referred as RESTful.

1. Client-server – By separating User Interface concerns from Data Storage concerns, we improve the portability of the User Interface across multiple platforms and scalability.
2. Stateless – Each request from client to server must contain all information necessary to understand the request. Session state is therefore kept entirely on the client.
3. Cacheable – All resources should allow caching unless explicitly indicated that caching is not possible.
4. Use of a Uniform Interface. Resources should be uniquely identifiable through a single URL, and only by using the underlying methods of the network protocol, such as DELETE, PUT, and GET with HTTP, should it be possible to manipulate a resource.
5. Layered System. REST allows for an architecture composed of multiple layers of servers.
6. Code on Demand (Optional). Most of the time a server will send back static representations of resources in the form of JSON or XML. However, when necessary, servers can send executable code to the client.

REST Request and Response

For a REST Request, it is important to know:

• The endpoint – a unique URL that contains the data objects or collection of objects
• The method – functions that perform corresponding operations which usually involve CRUD (Create, Reading, Updating and Deleting)
• The headers – fields providing instructions to the server
• The params – user specifications passed to the endpoint that affects the type of response generated
• The data (or body) – contains information you want to be sent to the server

For a REST Response, it can be data in the format of JSON or XML or any other media type. When something is not good, for example server is down, a response with an appropriate HTTP status code will be returned. We will look at more in the later chapters.

Postman and Example

Postman is a REST client tool that can be used for REST API testing. When we access a REST server by typing a URL in the browser, the method is GET by default. In order to test out different methods, headers, data body and other features of a REST service, we need to use a REST client like Postman.

The screenshot is an example of a REST request and response.

• \1. Http method set as POST
• \2. The target URL
• \3. Data body
• \4. Response status, 200 means success
• \5. Response data