Web Application Function

As illustrated in Figure 7-2, the flow of a web app is something like this:

1. A user makes a request in a browser for a particular website that has a web app incorporated.

2. The request is sent through the linkages of the Web to the appropriate web server for processing.

3. For the sake of the illustration, the initial request includes certain data that requires data to be extracted from a database and processing by a server-side web app.

4. The web app processes the request and passes the output back to the web server.

5. The web server returns the output to the requesting client.

This process is simplified, but only a bit. Should the web app not require interactions with other elements (databases, other web apps, etc.), it could run on the client machine through the browser just as easily. Another consideration is that the web app itself may call other web apps, which call other web apps, and on and on. As Gilster’s law says, “You never can tell, and it all depends.”

Let us look at an example of a webpage that includes static web apps. Remember that a static web app means it runs in the browser and not on a web server. This app is the beginning of a journey game in which the choices made by the player determine which web app is called. Figure 7-3 shows the landing page of the game.

The code that produces the webpage in Figure 7-3 is shown in Figure 7-4. As you can see, this is basic HTML coding that pulls in a CSS file for formatting and displays text. The two red lines are calls to web apps, which in this case are HTML files that continue the game with functional pages of the website displaying, based upon the user’s choices. It is as simple as that.

In the previous code sample, the anchor statements could just as easily have a program file name in the HREF reference. In place of the <a href=”journey.html”> statement, <a href=”journey.py”> accomplishes the same objective for the website, but with slightly different content in the file called. Regardless of the language, function, or process, the file being opened will take the focus of the current webpage. The web app could later return the focus to the calling page, or as in this sample application, the focus will continue to be passed from page to page.

Web Application Benefits

The benefits or advantages of using web applications in a website depend on a variety of factors. Most are subjective to the organization behind the website. However, the general benefits (and detriments discussed a bit later in this section) of developing and employing web applications are the same for any individual or organization that deploys a website. Web applications have some common benefits, including some already mentioned:

• Is not installed on the client-side host, so no hard disk space is required

• Maintenance is simplified as only one version and file is in use

• Provides the same function to all users

• Is not location-specific and can be accessed from anywhere an internet connection is available

• Is mostly operating system independent

• Is normally developed in common and well-known programming and scripting languages, such as HTML, CSS, and JavaScript

Web Application Disadvantages

Web applications, for as good as they sound, do present disadvantages and limitations. The following are downsides commonly cited that come from the use of web apps:

• Acceptance—A web app may be too advanced for managers or users in an organization, especially those who are uncomfortable with the internet, the Web, and especially the cloud. It is a widely shared misunderstanding that the cloud, and anything “in” the cloud, is not secure and vulnerable to attack and theft; many want to stay with a “proven” technology.

• Browsers—Browsers can be an issue. A webpage should be compatible with as many browsers as possible to provide for new versions and old versions of the popular browsers.

• Performance—A web app on a remote web server may be linked to another web app located on another remote web server. Depending on the specific actions required by the website, all or some of a web app chain is required to provide necessary functions on a single webpage. In these instances, any performance, response-time, or any communication or processor-related speed or timing issues are beyond the control of the website’s developer, especially if third-party web apps are involved.

• App problems—When a visitor to a website that incorporates web apps, especially third-party web apps, has problems with the app’s functioning, who should the visitor contact? The site operator, the site developer, the web app’s developer, or who? Who is able to respond and help to resolve the user’s issues?

Third-Party Apps Versus Third-Party Web Apps

Do not confuse third-party applications with third-party web applications. They are similar in what they do, who the developer may be, and how they are obtained for use. Third-party applications are software programs that users execute to gain access to certain features, services, or objects. For example, Chrome, Firefox, Edge, Safari, and Brave web browsers, Thunderbird, The Bat!, Paragon, and Pegasus email clients, anti-malware programs, software firewalls, graphics programs, or any program that works with any of the forenamed applications are all third-party applications.

Third-Party Web Apps

Web applications or web apps may or may not be from third parties. A web app that is developed by a website developer for use in a particular website is a first-party web app, but a third-party web app has the same characteristics of a third-party application.

Developing a web app follows a similar path as the development of a native application or system. If the goal for the web app is for it to become popular and be included in myriad websites, some important decisions need to be made: its purpose and scope, its features, and possibly, what its look and feel should be (unique or blend in with the calling website). From the business side of things, elements of its development also need to be addressed, including due date, project plan, testing, and performance. Another important decision concerns the application model it will follow. Following are the standard development methods for websites and mobile apps:

• Native application—A native app is developed for a specific operating system or platform using programming or scripting languages supported by that system. A native app incorporates the features and functionality of a native environment, meaning that each combination of platform and operating system is likely to require its own version of a native application. If the particular features and functions of a specific system are important to the purpose of the app, this is the type you would want to develop.

• Web application (web app)—As outlined earlier in the chapter, a web app is launched in a web browser on all internet-capable computing devices, including smartphones, notebook computers, tablets, and other types of mobile computing devices. A web app is developed to perform, complete, or compute an end result as a part of the function of a webpage. If the goal of a development project is to produce an application that can be used widely by a variety of users, then this is the type of app you should build.

• Hybrid application—This type of app is, as you may have already guessed, a combination of the native and web application development processes. The mix of characteristics can be more or less either of these two development objectives. A hybrid app may use webpage development tools, such as HTML, CSS, and JavaScript, or high-level programming languages like those mentioned earlier or newer languages like ObjectiveC or Swift.

Web App Architecture

The architecture of a web app defines its performance and user interface (UI) along with optimization characteristics that include search engine optimization (SEO), linkability (the attraction for other sites to link to it), and the complexity of its development. The various web app architectures are as follows:

• Server-side rendering (SSR)—SSR is the most basic of the website architectures. Most people know it as client/server architecture in which a client sends a request to a server for content. Any page preparation (rendering) required is performed on the web server and the display image is transferred to the client’s browser to be shown as is. The “traditional website” shown on the left side of Figure 7-5 illustrates an SSR structure.

• Static site generation (SSG)—In effect, an SSG website is stored on a content-delivery network (CDN) server completely rendered and ready to display. An SSG website is typically static and not overly complicated to speed up its transfer. The website data are not regenerated for each request, unless, of course, a change is made to the site. The data are passed through an API that constructs the display image. The image on the right side of Figure 7-5 illustrates an SSG architecture. Two of the more popular static website generators are Eleventy (www.11ty.dev) and open-source Hugo (gohugo.io).

• Single page application (SPA)—An SPA web application displays a one-page webpage and then, if required, updates the content of the page through an interaction with a server using JavaScript APIs. While an SPA page may not be the best format for SEO, it can have better performance than pages that load entirely each time. Without knowing it, you use SPA pages every day. Common SPAs are Facebook, Google Maps, GitHub, and Twitter.

• Progressive web applications (PWA)—This is a lightweight app format that runs on standard web browsers. A PWA operates like a native app, but it does not reside on the device on which it is running. PWA sites must be supported by the OS and the browser both. Typically, a PWA displays an operating system message box asking if an app should be added to the system. If accepted, the app is added to the system.

Application Programming Interface (API)

An application programming interface or an API, which is its most common name (pronounced as individual letters and not as “apy”), provides application developers with the capability to include common or routine tasks as well as complex actions in an app, avoiding repetitive or arduous programming time. It is safe to say that without the growing proliferation of APIs, the apps we use frequently would not be available at all.

In general, an API is a block of programming that is developed in a particular programming language or script that performs one or a collection of tasks. An analogy of an API is plugging an electrical appliance into a wall outlet. All you need to do is to insert the prongs of the electrical connector into the slots on the electrical outlet. This avoids the need to wire the device directly into the electrical system with all of its complications. When a particular type of action or capability is needed in a program, there is an API for that.

Another real-world analogy for how an API works is ordering a meal in a restaurant (the kind with a wait staff). You are the requesting application, the menu is the input data, the waiter is the API, and the kitchen is the web server. After processing the input, you decide on which application (meal) you wish to use (eat). You pass this information on to the waiter, who then translates your choice into kitchen-speak. The web server (kitchen) prepares a response (meal) and passes it to the API to be delivered to you, the client. You really do not care much about what happens in the kitchen as long as what you get is what you wanted. All you had to know is how to tell the API what it was you needed.

Like the waiter in the preceding example, an API is positioned between a web app and a web server and processes the data being transferred between the two. Where a user interface is intended for use by the user, an API speaks only to applications, web servers, and computers. To be a bit more specific, the use of an API works something like the following:

1. An application running on a client issues an API call or request, which instructs the API to perform an action; this request is then formatted by the API into a Uniform Resource Identifier (URI) that is passed to web server. The URI includes the request action, a header, and, when required, the body of the request. When an app communicates with another app, computer, or server, an API is acting as the interpreter.

2. The web server receives the URI and if the information is accurate and can be processed, gathers the data or information requested, inserts it into the URI, and passes it back to the API.

3. The API then extracts the data from the URI and passes it to the client.