Introducing the Node.js-to-AngularJS Stack
- Understanding the Basic Web Development Framework
- Understanding the Node.js-to-AngularJS Stack Components
- Up Next
The first section discusses various aspects of the general website/web application development framework, from users to backend services. The purpose of first covering the web development framework components is to help you more easily understand how the components of the Node.js-to-AngularJS stack relate to the pieces of the general framework. This should help you better see the benefits of using the Node.js-to-AngularJS stack components instead of the more traditional technologies.
Understanding the Basic Web Development Framework
To get you in the right mind-set to understand the benefits of utilizing Node.js, MongoDB, and AngularJS as your web framework, this section provides an overview of the basic components of most websites. If you are already familiar with the full web framework, then this section will be old hat, but if you only understand just the server side or client side of the web framework, then this section will give you a more complete picture.
The main components of any web framework are the user, browser, webserver, and backend services. Although websites vary greatly in terms of appearance and behavior, all have these basic components in one form or another.
This section is not intended to be in-depth, comprehensive, or technically exact but rather a very high-level perspective of the parts involved in a functional website. The components are described in a top-down manner, from user down to backend services. Then the next section discusses the Node.js-to-AngularJS stack from the bottom up, so you can get a picture of where each of the pieces fits and why. Figure 1.1 provides a basic diagram to help you visualize the components in a website/web application, which are discussed in the following sections.
Figure 1.1 Basic diagram of the components of a basic website/web application.
Users are a fundamental part of every website; they are, after all, the reason websites exist in the first place. User expectations define the requirements for developing a good website. User expectations have changed a lot over the years. In the past, users accepted the slow, cumbersome experience of the “world-wide-wait,” but not today. They expect websites to behave much more quickly, like applications installed on their computers and mobile devices.
The user role in a web framework is to sit on the visual output and interaction input of webpages. That is, users view the results of the web framework processing and then provide interactions using mouse clicks, keyboard input, and swipes and taps.
The browser plays three roles in the web framework:
- Provide communication to and from the webserver
- Interpret the data from the server and render it into the view that the user actually sees
- Handle user interaction through the keyboard, mouse, touchscreen, or other input device and take the appropriate action
Browser-to-webserver communication consists of a series of requests, using the HTTP and HTTPS protocols. Hypertext Transfer Protocol (HTTP) is used to define communication between the browser and the webserver. HTTP defines what types of requests can be made as well as the format of those requests and the HTTP response.
HTTPS adds an additional security layer, SSL/TLS, to ensure secure connections by requiring the webserver to provide a certificate to the browser. The user can then determine whether to accept the certificate before allowing the connection.
There are three main types of requests that a browser will make to a webserver:
- GET: The GET request is typically used to retrieve data from the server, such as .html files, images, or JSON data.
- POST: POST requests are used when sending data to the server, such as adding an item to a shopping cart or submitting a web form.
Rendering the Browser View
The screen that the user actually views and interacts with is often made up of several different pieces of data retrieved from the webserver. The browser reads data from the initial URL and then renders the HTML document to build a Document Object Model (DOM). The DOM is a tree structure object with the HTML document as the root. The structure of the tree basically matches the structure of the HTML document. For example, document will have html as a child, and html will have head and body as children, and body may have div, p, or other elements as children, like this:
document + html + head + body + div + p
The browser interprets each DOM element and renders it to the user’s screen to build the webpage view.
The browser often gets various types of data from multiple webserver requests to build a webpage. The following are the most common types of data the browser uses to render the final user view as well as define the webpage behavior:
- HTML files: These provide the fundamental structure of the DOM.
- CSS files: These define how each of the elements on the page is to be styled, in terms of font, color, borders, and spacing.
- Media files: Image, video, and sound files are rendered as part of the webpage.
- HTTP headers: HTTP defines a set of headers that the browser can use and client-side scripts to define the behavior of the webpage. For example, cookies are contained in the HTTP headers. The HTTP headers also define the type of data in the request as well as the type of data expected to be returned to the browser.
A webserver’s main focus is handling requests from browsers. As described earlier, a browser may request a document, post data, or perform an AJAX request to get data. The webserver uses HTTP headers as well as a URL to determine what action to take. This is where things get very different, depending on the webserver, configuration, and technologies used.
Most out-of-the-box webservers such as Apache and IIS are made to serve static files such as .html, .css, and media files. To handle POST requests that modify server data and AJAX requests to interact with backend services, webservers need to be extended with server-side scripts.
A server-side script is really anything that a webserver can execute in order to perform the task the browser is requesting. These scripts can be written in PHP, Python, C, C++, C#, Perl, Java, ... the list goes on and on. Webservers such as Apache and IIS provide mechanisms to include server-side scripts and then wire them up to specific URL locations requested by the browser. This is where having a solid webserver framework can make a big difference. It often takes quite a bit of configuration to enable various scripting languages and wire up the server-side scripts so that the webserver can route the appropriate requests to the appropriate scripts.
Server-side scripts either generate a response directly by executing their code or connect with other backend servers such as databases to obtain the necessary information and then use that information to build and send the appropriate responses.
Backend services are services that run behind a webserver and provide data that is used to build responses to the browser. The most common type of backend service is a database that stores information. When a request comes in from the browser that requires information from the database or other backend service, the server-side script connects to the database, retrieves the information, formats it, and then sends it back to the browser. On the other hand, when data comes in from a web request that needs to be stored in the database, the server-side script connects to the database and updates the data.