11.1 Modern Web Applications Architectures

Server-Side Rendering and MVC Patterns

The Web transitioned from its 1.0 phase, where the primary usage was viewing content composed of text and images, to its 2.0 phase of user interaction. As it evolved, three technologies dominated the Web’s programming landscape, commonly referred to as the trifecta:

• hypertext markup language (HTML): a standard markup language used to describe the structure and content of web pages.
• cascading style sheets (CSS): a standard style sheet language used to alter the presentation style of the content found in HTML (or other markup languages).
• JavaScript (JS): a scripting language that adds interactivity to web content and server-side functionality. Various other scripting languages and competing approaches were used prior to the adoption of JavaScript.

The adoption of HTML was already a given on the Web, and with the introduction of CSS in 1996, a stronger push for separating content and style was introduced so that the styling of content could be specified solely as part of style sheets rather than HTML tags. Web pages at this time mostly consisted of static content, which would be generated and delivered on the web server. Essentially, the user would select an action in their browser that sent an HTTP request to the server such as the following:

• When clicking a hyperlink on a web page, the browser would send an HTTP GET request to the web server. This request asked for a specific resource (such as a web page or an image), and the server would respond by sending the requested data back to the browser.
• When filling out a form on a web page and clicking the submit button, the browser would send an HTTP POST request to the server. This request included the data that was entered (like a username and password), and the server processed it and responded accordingly.

Essentially, the web server performed all the HTML content rendering on the server side, and the client (web browser) would present what it received. The browser in this model acts as a thin client, as it has minimal functionality. Figure 11.4 illustrates the components of a traditional Web 2.0 architecture using Java-based technologies. Notice the shift in user interaction with the website compared with a Web 1.0 website. Also note that users are able to interact with applications via an application server that can retrieve data from a database or file system. This enables support for managing web sessions that allow navigation across multiple pages.

Figure 11.4 This illustrates a user’s interaction with a traditional Web 2.0 architecture. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Many of the original web applications were stateless, meaning that prior requests had no bearing on future requests. For example, it was not possible to create a shopping cart as part of a web session that would keep track of the session and what was purchased on a site and maintain the state (i.e., content in this case) of the cart. In contrast, a stateful application is software that maintains the state of an application over time, while in the case of a stateless application, state is not maintained by the system and previous actions do not impact future ones. Stateless applications are simpler and easier to implement and maintain but offer limited functionality.

As previously mentioned, Web 2.0 was partly driven by user demand for more interactive functionality. Interactivity requires maintaining some state (e.g., the web session and the content of the cart as per the previous example), thereby increasing the system’s complexity. This increased the demands on the web server for almost all the processing needed to generate and present the website content. Increased functionality led to more complex systems, and a clear separation of responsibility between the website’s rendition, business logic (i.e., the logic implemented as part of the web application), and persistence layers were needed to improve the quality and performance of the website while leveraging engineering expertise in given domains.

As you learned in Chapter 10 Enterprise and Solution Architectures Management, the Model-View-Controller pattern is tailored to address this separation of responsibility. In the MVC pattern, the Model is the persistence layer responsible for data storage and retrieval. It has a well-defined API that the Controller uses. The View is the presentation layer that handles the user interface. Finally, the Controller acts as the business logic layer that performs processing and enforces rules to generate applicable content within a given application domain and separates the user interface from the data. It also has a well-defined API that the View understands. The best-practice design concept used to create software systems in a way that ensures weak associations with other components is called loose coupling. This concept allows for separation of concerns between components, which leads to maintaining high cohesion within websites’ functionalities. MVC components are loosely coupled in that the various components can interact with one another to access the specific functionalities provided by each component. High cohesion ensures that everything that is needed to provide a specific functionality is included in one of the components. For example, on a banking website, functionality for deposits and withdrawals may be collocated on the server within the same component to ensure high cohesion; however, features for applying for a loan may be located within another component. Three popular server-side web application frameworks that implemented the MVC pattern were Apache Struts, ASP.NET, and Ruby on Rails.

The server side performs the majority of the functionality. It uses a combination of templated HTML, controller and application server technologies (e.g., ASP.NET, C#), and SQL. JavaScript is sent to the browser using jQuery for cross-browser support, or it may use Asynchronous JavaScript and XML to communicate with the web server without refreshing the page. Asynchronous JavaScript and XML (AJAX) exchanges small amounts of data between a client and server. The engineering team using such a web platform must understand and enforce the separation of responsibilities between the MVC components to ensure future modifications, especially significant changes, can be made without rearchitecting the system. Because the engineering team needs to know different programming languages for different layers, there may be some internal resistance to this, and it may be tempting to go around a layer to make a quick fix. Essentially, making sure that the architecture of the web platform is understood and used properly, architectural adherence is predicated on the expertise of the engineering team members and more on the nature of the tools used.

Responsive Web 2.0 Applications

By the mid-2000s, JavaScript became popular for client-side browser functionality. AJAX and jQuery technologies allowed developers to create single-page applications (SPA). For the end user, SPAs offered functionality like a traditional desktop application and drastically improved user experience by reducing latency. No longer were expensive web server requests needed that resulted in full page refreshes in the browser. Instead, small data transmissions could be sent and received between the browser and server through AJAX. Figure 11.5 compares the life cycle of SPAs to a traditional Web 2.0 application.

Figure 11.5 This is a comparison of the life cycles between traditional Web 2.0 applications and SPAs. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

jQuery, an open-source JavaScript library, ensured that web developers could write JavaScript for a generic browser document object model (DOM) that would run regardless of the user’s browser. The DOM is a programming interface provided by browsers. It allows scripts, written in JavaScript for example, to interact with the structure of a web page. When a web page is loaded into the browser, the browser creates a DOM of the page. The DOM structure is a hierarchical treelike structure that organizes the elements of the page as objects. The model used by the DOM enables dynamic access and facilitates the manipulation of content, structure, and style of web pages. Figure 11.6 illustrates a typical SPA architecture where a single web page is delivered to the browser. Note that in this model, the user’s interaction with the site has increased in the amount of content generated by the user.

Figure 11.6 This illustrates a user’s interaction with a single-page application (SPA). (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

The more sophisticated SPAs required large amounts of JavaScript on the client side. Many end users had underpowered machines or out-of-date web browsers, and the SPAs performed poorly.

In the early 2010s, web application frameworks were introduced to create complex, client-side web applications that performed well, gave a native desktop application-like experience, and were easier for developers to create. These applications followed a Model-View-ViewModel (MVVM) pattern. Figure 11.7 illustrates the relationship between the View, ViewModel, and Model components.

Figure 11.7 Various data binding, events, and actions occur between the components of the Model-View-ViewModel pattern. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

This pattern is like the MVC pattern we’ve previously explored; however, several key differences exist. The following are some of the similarities and differences:

• The View is responsible for the presentation and only interacts with the ViewModel. This is similar in responsibility to the View role and interaction with the Controller in the MVC pattern. The View here binds to functions and properties in the ViewModel and receives notifications on operations and changes to the data. It doesn’t interact directly with the Model.
• The Model is similar to the Model in the MVC pattern and is responsible for data retrieval and storage. It doesn’t know anything about the ViewModel.
• The ViewModel is similar to the Controller in that it decouples the relationship between the View and Model and handles data manipulation. The ViewModel responds to notifications from the Model and will send events to the View if needed. Because the View binds to the ViewModel, the ViewModel doesn’t know anything about the View. The ViewModel can work with a local Model in the browser, a remote Model, or both.

Unlike the previous MVC pattern regarding server-side rendering, the MVVM pattern is run entirely in the client. A Representational State Transfer (REST) API decouples the client-side Model and ViewModel components from the server-side business logic and persistence store. REST-based (aka RESTful) APIs follow the architecture style designed for the Web. These APIs use the JavaScript Object Notation (JSON) file format that represents data as text-based attribute-value information. Figure 11.8 illustrates the MVVM pattern as it applies to an SPA.

Figure 11.8 This illustrates the Model-View-ViewModel pattern as applied to the SPA architecture. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

As you can see from the diagram, this model is more complex than the simpler MVC pattern. The quality of the APIs partly determines the effectiveness of this pattern. REST-based APIs benefit from being discoverable (i.e., all API URIs can be found from the root API node) and should be versioned (i.e., to keep track of changes to interfaces for compatibility purposes) so that upgrades don’t break API users. Without API versioning, coupling between client and server increases (due to semantic and syntactic coupling), and upgrades become costly. Similar to a URL, a Uniform Resource Identifier (URI) is a string of characters that identifies a resource on the Web.

Regardless of these flaws, early browser-based frameworks proved the value of creating rich client-side apps. Web standards evolved, and newer frameworks emerged that adhered to the newer standards and solved many of the problems of their predecessors. Popular SPA frameworks include Angular, Ember.js, React, and Vue.js. These are often used in conjunction with server-side tools, creating a “full stack” of technologies for developing the solution. A popular server-side technology in this stack is Node, a runtime environment for executing JavaScript code.

Approaches to minimizing the data transferred between the APIs and the client to reduce network traffic or simplifying access to the data resulted in two primary approaches. One was flattening the data model. Instead of returning data in a nested format (such as from a relational database), the returned data would be “flattened” to a series of key-value pairs, each resulting in a unique return value. If the specific request could be made, the flattened data would be preferred to navigating the nested data to improve performance. However, creating APIs to fit specific requests could be challenging. Another solution was using GraphQL, an open-source query and manipulation language. With GraphQL, callers of its API could craft specific requests to return only the needed data, which made access to many services such as the ones provided by microservices architectures more scalable.

Native Mobile Applications

Native mobile applications are designed to run on specific mobile operating systems (i.e., Android, iOS). Android and iOS operating systems dominate the mobile device market. In 2023, Android had approximately 70% of the worldwide market share, with iOS at around 29%. Samsung, KaiOS, Windows, Linux, and others make up the remaining 1% of the market.²

However, in the United States in 2023, iOS was the predominant OS with roughly 61% of the market and Android at 38%. Here, we’ll look at the specifics of native mobile app development by focusing on Android and iOS.³

Web 3.0 Applications

Web 3.0 is the next phase of the Web. It is still being realized, and similar to Web 1.0 and 2.0, it can only be fully understood in hindsight. The technology and uses of the Web overlap between the phases, with newer phases becoming preferred over their predecessor phases. If Web 1.0 was the read-only web, and Web 2.0 was the participation (write) web, then Web 3.0 may be the read, write, and execute web.

Tim Berners-Lee had referred to Web 3.0 as the Semantic Web, a system of autonomous agents, which are software programs that respond to events. That model has shifted over the years. While AI (and other technologies such as AR/VR) will likely form a part of Web 3.0 or Web x.0, the principles that govern the next phase are expected to be around a web that is decentralized, permissionless, and trusted.

Web 3.0 sees a shift from the more traditional client-server model to a peer-to-peer networking model. A peer-to-peer network is one in which devices connect and can share data and processing without needing a centralized server. Peers in this scheme can perform the role of a traditional client, server, or both. This shift will foster a trusted, decentralized, and open web, where large companies don’t own the data, but everyone collectively owns it. Technologies such as a smart contract allow a trusted model that is needed in a decentralized system. Artificial intelligence and machine learning will improve information access through understanding the meaning of content available on the Web. The exemplar apps of the Web 3.0 phase will be defined in the future. Still, if the previous phases of the Web are any indication, it will fundamentally change how we operate in an ever-evolving technological world.

Finally, Web 3.0 apps will run on a web that supports Web 1.0 and 2.0 apps, with the likely result being hybrid architectures that are partially Web 2.0 and 3.0.

Web 3.0 Application Architectures

Web 3.0 apps are architected without a centralized server, so they are considered to be decentralized Apps (DApps), which are applications that execute smart contracts and run over distributed ledger technology (DLT). Smart contracts are programs that can be executed on a distributed ledger. Distributed ledgers use independent network nodes to record, share, and synchronize transactions in their respective electronic ledgers instead of keeping them in a centralized server. The code is visible to all parties, and trust is put into the code instead of a centralized third party. Distributed ledgers chronicle transactions between accounts that are recorded in multiple places. Blockchain is a type of DLT.

Let’s compare a traditional Web 2.0 application with a 3.0 DApp. In Web 2.0, if you created a website for users to post pictures and make comments on them, you would need functionality for authenticating users, authorizing their actions, generating a UI for adding images, browsing images, and posting comments. To do this, you would need a front-end web server and back-end processing for business logic and data storage. These servers would run in a company’s data center or on a cloud provider. The company would own all the code and data, including metadata about how you interact with the website (e.g., what you commented on, how long you looked at a picture). As a reminder, Figure 11.4 illustrates a traditional Web 2.0 architecture (note: for our purposes, the SPA architecture could also be used here).

In a Web 3.0 DApp, the functionality for creating an application for posting pictures and commenting on them would remain the same. The principal differences would be where the code runs and who owns the code and data. Let’s break this down into a series of steps that shift away from a centralized solution to a distributed one.

To start, we can keep the web server’s front end and replace the back-end code with the distributed application. The Ethereum blockchain, as an example, is a deterministic state machine that runs on a peer-to-peer network. A deterministic state machine has a model of computation that relies on a finite number of states and transitions between them to respond to inputs. It guarantees a single transition from one state to another in response to an input. Because it is based on a deterministic state machine, the Ethereum blockchain is often referred to as a “world computer.” Ethereum blockchain transactions are calls to methods that are implemented in smart contracts. These method calls result in change to the data (aka, state) that is maintained by the contracts within the blockchain. The Ethereum blockchain records transactions into blocks that are added to its blockchain. Changes to the state machine itself (e.g., modify the block or transaction data structures used in the Ethereum blockchain) require consensus between the node providers that support the peer-to-peer blockchain network. Anyone in the world can read or write to the machine—a central authority does not govern it.

Smart contracts form the code and are written in high-level languages like Solidity or Vyper. The high-level contract code is compiled into bytecode that can be executed on the Ethereum Virtual Machine (EVM). Each block contains a hash pointer of the previous block, with a time stamp and the transaction data. The hash pointer includes a cryptographic hash (i.e., a fixed-size digest of the previous block that makes it possible to verify that the previous block was not changed since it was stored in the blockchain; the cryptographic part ensures that the hash value has some special properties and, in particular, that the original data cannot be derived from the hash value).

Figure 11.9 replaces the traditional back-end components of a website with a blockchain. The user’s interaction with the website is consistent with a traditional Web 2.0 website, as the back-end processing is hidden from the user, though it has been replaced with a blockchain node.

Figure 11.9 Here is a traditional Web 2.0 website with back-end components replaced with a DApp. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

In the figure, the web server talks to a node of the blockchain, referred to as a full node. A full node is a computer that maintains a copy of the blockchain and runs blockchain software. Operating a full node can become expensive because you need to provide the hardware and pay a fee to join the Ethereum network. Blockchain end users typically use a software wallet such as MetaMask to access nodes in the blockchain or use a third-party wallet offered by providers like Infura, Alchemy, or QuickNode. MetaMask is a wallet technology that stores a user’s private keys in their browser.

Blockchain providers use the JSON-RPC specification for managing communication from clients/end users. This remote procedure call (RPC) is lightweight and transport agnostic.

As previously mentioned, any client can access the blockchain via a wallet provider, which requires creating an account and obtaining a wallet ID. Once logged into their wallets, clients can perform blockchain transactions, which end up reading and/or writing to the blockchain and changing the state of smart contracts. The wallet ID is used to sign transactions so they can be traced to the client wallet. In our example, browsing photos on the Web 3.0 application is a read transaction that would not require signing anything; however, adding photos and comments would.

Adding data to the blockchain incurs a cost as nodes now need to store that data. The user incurs this expense. Imagine paying every time you upload a photo to your favorite social media app. Instead of storing the data on the blockchain, a cost-effective approach would be to store the data using the InterPlanetary File System (IPFS) protocol. IPFS is a peer-to-peer distributed file-sharing protocol. You can go through a provider like Pinata to get a hash value for the data (i.e., a fixed length digest of the data that cannot be used to obtain the original data) you upload to the IPFS and store that hash value in the blockchain via a smart contract interface, thereby reducing the storage cost of data within the blockchain.

Figure 11.10 shows the addition of:

• the provider between the web server and the DApp
• a signer for when the user wants to write to the application
• the inclusion of the IPFS for data storage

Figure 11.10 This architecture has added a signer, provider, and IPFS. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Up to this point, we’ve kept the front-end logic on a web server hosted in a centralized location. This is a good temporary approach for an organization that wants to transition a legacy solution to a DApp over time. Because IPFS will host some of the data of the DApp, let’s move the front-end HTML, CSS, and JavaScript there and load it into the browser like an SPA app.

Like an SPA, we want the application to run asynchronously and respond to events (like changing data) as they occur. Web3.js is a JavaScript library that uses the JSON-RPC to respond to events fired when smart contracts execute. Alternatively, The Graph is a solution that uses GraphQL to make it easier to query data on the blockchain.

Figure 11.11 shows the updated architecture with the front-end residing in IPFS and the addition of The Graph (listed as GraphQL) for improved querying of the blockchain.

Figure 11.11 The front-end web page has been moved to IPFS, and graphing query capabilities have been added. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

This results in a Web 3.0 application; however, there are problems with this architecture that we will examine next.

Web 3.0 Application Challenges

Blockchains currently have a scaling problem. The average size of a block has increased over the years, and transaction fees are associated with each transaction. A common fee is the gas price, which is the cost of validating transactions and updating ledgers. Additionally, negative performance can occur on a blockchain with large amounts of transactions.

One approach to help with scaling is the use of sidechains. A sidechain is a secondary (i.e., level 2 or L2) blockchain that increases the blockchain network performance by aggregating transactions off-chain (i.e., off the mainnet/Ethereum network) and committing them to the mainnet at once. Polygon is a popular L2 scaling system for sidechaining. Other L2 scaling techniques include blockchain rollups, which are protocols designed to enable high throughput and lower costs. They address scaling by bundling transactions and reducing data sizes to increase transaction efficiency and limit storage costs. Examples of blockchain rollups include optimistic and zero-knowledge rollups. An optimistic rollup is a protocol that increases transaction output by bundling multiple transactions into batches, which are processed off-chain. In this case, transaction data is recorded on the mainnet via data compression techniques that lower cost and increase transaction speed. Optimistic rollups on Ethereum can improve scalability by a factor of 10 to 100. A zero-knowledge rollup (zk-rollup) is a protocol that bundles transactions into batches that are executed off the mainnet. For every batch, a zk-rollup operator submits a summary of required changes once the transactions in the batch have been executed. Operators have also produced validity proofs that demonstrate that the changes are accurate. These proofs are significantly smaller than transaction data so it is quicker and cheaper to verify them. Additionally, zk-rollups are used on Ethereum to reduce transaction data size via compression techniques, which ends up reducing user fees.

Figure 11.12 shows the addition of sidechains to the architecture to mitigate some of the challenges associated with Web 3.0 DApps. Notice how the user’s interaction with the Web 3.0 app has grown from mostly reading content in a Web 1.0 model to more fully participating in the content and functionality of the Web 3.0 app.

Figure 11.12 The user’s interaction with the full Web 3.0 application is highlighted here. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

As you can see, the architecture has become rather complex to support DApps effectively. However, Web 3.0 is still in a nascent phase, and currently there are several solutions and tools being developed to make building and deploying Web 3.0 DApps even easier. Hardhat is a developer ecosystem for building and deploying smart contracts on a local network for testing.

This architecture focused on blockchains and used Ethereum as the principal implementation. However, there are other DLT solutions. Hashgraph is an approach where only selected nodes store the entire blockchain, and voting mechanisms are introduced to validate if the blocks are correct. Stacks is another DLT where only the smart contracts are decentralized, and the data is controlled by its owner. Owners can share or remove it—ensuring data privacy.

Technology in Everyday Life

Use of Frameworks

Web applications are used today to power commercial websites that are accessed by people to complete online transactions to buy goods of any kind. Mobile web applications and native versions of such are also available on smartphones and watches to help do the same. How does using web and native application frameworks help people in everyday life? Provide a couple of illustrative scenarios to explain your opinion. Your scenarios should not be limited to describing how the frameworks are used, but rather describe situations where these frameworks are applied in real life.

Hybrid Web 2.0/3.0 Applications

Due to the qualities and limitations of Web 2.0 and 3.0 architectures, it is likely that we’ll see solutions that are a combination of the two approaches and leverage their best attributes. One way to do this would be to have workflow processes that require a high rate of change implemented in a Web 2.0 architecture, while processes that would benefit from using a distributed ledger being executed in Web 3.0. For example, traditional commercial websites can keep using the Web 2.0 architecture, while payment solutions can be extended by accessing the Web 3.0 architecture to make payments using cryptocurrencies (e.g., Bitcoin).

Let’s consider an app for generating AI artwork. Many solutions exist today for doing this; however, we want our app to give “ownership” to the digital artwork a person generates. AI models are trained to recognize existing artwork (e.g., paintings available via the wikiart.org API) that may be copyrighted—so ownership is still being determined in the courts. Here, the term ownership is used to attribute AI image creation and nothing more. While AI models are very popular, some companies do not want to share data with AI model creators and prefer to have the AI models deployed in their own infrastructure to ensure full privacy. A non-fungible token (NFT) is a unique digital identifier on a blockchain that a user may want to create of their image and possibly sell (i.e., transfer ownership) on a marketplace. A common use case for this app might be:

1. A user logs in to the website and enters a prompt to generate an image.
2. After several rounds of adjusting their prompts, they end up with an image they want.
3. The user pays to have a non-fungible token created of the image, which is stored on a blockchain marketplace for sale.

As you can imagine, running an AI image generator on a blockchain might not perform well. Likewise, creating NFTs without blockchain technologies is counterintuitive. Therefore, the architecture for this solution needs to encompass both Web 2.0 and 3.0 approaches.

Figure 11.13 shows how the APIs will do the heavy lifting of working with the AI model to generate the artwork. Once the user is satisfied, they will interact with aspects of the UI that execute smart contracts to generate and add the NFT to the blockchain. Transactions will happen on the blockchain. APIs may interact directly with the blockchain, looking for similar works.

Figure 11.13 This outlines the user’s interaction with a hybrid Web 2.0/3.0 application. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

This model still has a centralized Web 2.0 server for artwork generation and account management; however, portions that deal with NFT ownership and selling of that ownership are managed within the Web 3.0 blockchain infrastructure. This approach serves the needs of many businesses that want to take advantage of Web 3.0 features while preserving their original Web 2.0 websites.