Back-end programming

software architecture

Web Application Architecture

World wide web

Commonly referred to as WWW, or the Web, is an interconnected system of public documents and other web resources, accessible through the Internet.

It is NOT the same as the Internet.

Tim Berners-Lee proposed the architecture of the Web in 1990. He created the first web server, web browser, and webpage.


The Web consists of several components, including the HTTP protocol, URL/URI, and HTML.

World wide web


Uniform Resource Identifier (URI) is a text string that refers to a resource. The most common are Uniform Resource Locators (URLs), that specify the location of the resource, including the protocol used to access it.

The browser displays URLs in its address bar.


Hypertext is text which contains links to other texts.

HyperMedia is a term used for hypertext which is not constrained to be text: it can include graphics, video and sound , for example.


HyperText Markup Language (HTML) is a descriptive language that specifies webpage structure.

An HTML document is a plaintext document structured with elements.

<!DOCTYPE html>

    <meta charset="utf-8">
    <title>A beautiful web page!</title>

    <h1>Page Content</h1>
    <p>The main content of a web page appears inside the <b>body</b> tag.
        There are several other elements you can use to create the page
        with whatever content you see fit.</p>


The http protocol

The Hypertext Transfer Protocol (HTTP) is the underlying network protocol that enables the transfer of resources on the Web.


It follows a classical client-server model. The client opens a connection to make a request and waits for a response.


HTTP is textual and stateless (the server doesn't keep any data between two requests).

HTTP REquest methods

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource.

GET Requests a representation of the specified resource
POST Used to submit an entity to the specified resource, often causing a change in state or side effects on the server
PUT Replaces all current representations of the target resource with the request payload
DELETE Deletes the specified resource

HTTP REquest methods

HTTP status codes

HTTP response status codes indicate whether a specific HTTP request has been successfully completed.



Two command line tools that provide a mechanism for non-interactive download and upload of data. We can use them for web crawling, automating scripts, testing of APIs, etc.


The main difference between them is that curl will show the output in the console, whilst wget will download it into a file.

// Dump to screen the contents of the index page at
$ curl

// Create a mirror image of site
// Saving the log of the activities to a log file
$ wget -r -o mindswap.log



The Web Server


Application Layering

As applications become more and more complex, the necessity to separate all the concerns in one system rises.

Layering is one of the most common techniques used to break apart a complicated software system.

Application Layering

In a layered architecture, components are organized into layers: isolated and independent, each layer has a specific responsibility within the system.


Communication is usually performed throughout the layers, e.g., a request from Layer 1 must go through Layer 2 to get to 3. 

This closed nature of  the layers allows for easier updates: changes on a specific layer or component will have lesser impact on other layers.

Application Layering

The layered architecture is an intuitive pattern to use, as it is quite common and not very complex (even with larger number of layers). They are also easy to test and update at a layer level.


It can have some drawbacks, particularly in terms of scalability and performance. Some changes may require alterations in all layers, which can be cumbersome for larger projects.


In terms of performance, the linear communication through each layer can lead to slower processes



Software architectural pattern that divides a software application into three interconnected parts. This division aims to separate the internal representation of data from the way that data is presented to the user.


The MVC pattern is sometimes used as part of a layered architecture for larger systems. In this case, it is commonly part of the presentation layer.


Represents the application's domain data and business logic.


Usually related to a persistence mechanism.


It contains no logic describing how to present the data to the user.


Represents the user interface, presenting data to the user, as well as the interaction elements.


The view knows how to access the model’s data, but it does not know what this data means or what the user can do to manipulate it.


An intermediary between the model and the view.  


It listens to events triggered by the view (or another external source) and executes the appropriate reaction to these events.


  1. User interacts with a view
  2. View alerts controller of a particular event
  3. Controller updates the model
  4. Model alerts view that it has changed
  5. View grabs model data and updates itself

MVC Variations

MVP - The Presenter is given complete access to a view that is generally very passive, and that responds to data binding but nothing else.


The View and Presenter have a one-to-one relationship, and communication between the components is usually performed through interfaces.

MVC Variations

MVVM - Use of a declarative view with data bindings to the view model, allowing a true separation of work on Views (designers) from other layers (developers).


View and ViewModel have a many-to-one relationship, where several Views can be bound to the same ViewModel to receive and send updates.



We are going to develop a simple login system, using a MVC architecture.


Users of our system will be asked to provide a username and a password, which will be compared to our list of existing users.


If that username-password combination exists, then the login is successful, and the user is welcomed into the main system. Otherwise, it will ask for the credentials again.

Service layer

Business logic

Business logic is defined as the functionality that handles the exchange of information between the application's persisted data and the user interface.

Considering an application that stores data regarding library users and the books they've borrowed, which operations would you implement?


Where would you implement those operations?

Business logic In MODEL

This is a common practice, but it scales poorly.


In addition to holding the data to be persisted (username, id, books borrowed, as well as book names, ISBNs, etc.), stuffing the models with additional responsibilities will quickly make them too complex. Furthermore, this practice will possibly require some coupling to other models.

Business logic In Controller

Handling user interface actions, data access and business logic all in one place is an anti-pattern.


Business logic should be protected from user interface concerns, at all costs.

Service Layer

The best solution is to create a fourth layer: the Service Layer.


To implement this, we will extract business logic and data access code into Services. The Controller must take request data and pass it into the Service layer.


The Does-Nothing User Application

Application programming interface


API is a software intermediary that, by exposing the public functionality of one application, allows two applications to talk to each other.


These applications do not need to know how the other is implemented.


Ex: Flight booking websites, Google Maps

How it works

  1. A client application initiates an API call to retrieve information; It includes a request verb, headers, and sometimes, a request body.
  2. The API makes a call to the external program/server
  3. The server responds back to the API with the requested information
  4. The API transfers data to the initial requesting application

Characteristics of a modern api

  • Adheres to standards that are developer friendly.
  • Designed for consumption for specific audiences
  • Documented
  • Has its own software development lifecycle


In terms of access, an API can be released as:

  • Private, to be used only internally within a business/company
  • Partner, where 3rd party companies can have approved access
  • Public, where the API is available to the public


The stability of an API is important, particularly for more open APIs, to avoid client-side issues and facilitate updates.

api Protocols

With the increase in web API use, certain protocols have been developed to provide users with rules that specify the accepted data types and commands supported by the API itself.


These protocols facilitate standard information exchange.

Popular api Protocols



Simple Object Access Protocol



Representational State Transfer


API protocol built with XML and schemas, which makes it a strongly typed messaging framework. It is a W3C recommendation.


It facilitates communication between applications in different environments/languages, through HTTP or SMTP.


Every operation is explicitly defined, as well as the overall message structure.


<?xml version="1.0"?>


<soap:Body xmlns:m="">



A set of web API architecture principles. It is more of an architectural pattern, not exactly a protocol.


A REST API uses HTTP to process CRUD data requests.

XML, JSON and other formats are accepted.

RESTful api

An API is considered RESTful if it conforms to these constraints:

  •  Client-server architecture
  •  Statelessness
  •  Cacheability
  •  Layered system
  •  Uniform interface
  •  Code on demand (optional)
  “customer”: {
    “name” = “Mariah Carey”,
    “email” = “”


SOAP is language, platform, and transport independent, while REST requires the use of HTTP protocol. It is also standardised and has a built-in error handling system.


REST is easier to use (smaller learning curve) and more flexible. It is also faster and closer to other Web technologies in design philosophy.

Web services

Web Services

Software components that can be accessed via a web address, therefore requiring a network. It provides a web-based interface to other applications.


Web services may be implemented using SOAP, developed as RESTful APIs, or other similar protocols.



When using Web Services, there are two common architectural approaches:

  1. Service-Oriented Architecture
  2. Microservices Architecture

Service-Oriented Architecture

SOA is a software design style where the features are split up and made available as separate services within a network.


These services are self-contained, reusable and easily incorporated into new applications within a system.

Microservices Architecture

Divides an application into smaller, independent components, making them easier to test, maintain, and scale.


Microservices are a cloud native architectural approach, typically used to build individual applications in a way that makes them more agile, scalable, and resilient.

The main difference between SOA and Microservices is scope.

Serverless architecture

* As a Service

*aaS is an acronym that refers to something being presented to a customer as a service, in the context of cloud computing.



  • Scalability
  • Quick deployment
  • Quick updates
  • No server management



  • Testing/debugging is more challenging
  • New security concerns
  • Expensive long-running processes

Serverless computing is a method of providing backend services on a pay-as-you-use basis.


Slack uses a serverless application called marbot to send notifications from Amazon Web Services (AWS) to DevOps teams through Slack.

HomeAway relied on Google Cloud Functions to develop an app that allowed users to search and comment on the recommendations of travellers in real time.

Coca-Cola embraced serverless after its implementation in vending machines resulted in significant savings.

Software Architecture

By Soraia Veríssimo

Software Architecture

  • 1,594