Throughout this course, we will be working almost exclusively in the following environments:
“Visual Studio Code is an open-source (free) streamlined code editor with support for development operations like debugging, task running and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs”. Visual Studio Code also runs on Mac OS X, Linux and Windows operating systems, which will provide the class with a single unified environment to work in regardless of a student’s choice of laptop or home computer. Some of the noteworthy features of Visual Studio Code Include:
“In Visual Studio Code, you can open an integrated terminal, initially starting at the root of your workspace. This can be very convenient as you don’t have to switch windows or alter the state of an existing terminal to perform a quick command line task”.
To open the terminal:
File & Folder Based
Since VS Code is file and folder based – you can get started immediately by simply opening a file or folder in VS Code.
“On top of this, VS Code can read and take advantage of a variety of project files defined by different frameworks and platforms. For example, if the folder you opened in VS Code contains one or more package.json (which we will be making extensive use of during the semester), project.json, tsconfig.json, or .NET Core Visual Studio solution and project files, VS Code will read these files and use them to provide additional functionality, such as rich IntelliSense in the editor”.
Visual Studio Code has integrated Git support for the most common commands. Git is essentially an open-source “Version Control” System, often used by developers in a team setting (GitHub) to manage updates to their code in a centralized location, while also maintaining a history of changes (versions). While we will not be using Git or GitHub in this class, Git is an extremely popular Version Control System used for both commercial and open-source projects around the world and having integrated access to the commands from within our IDE is a valuable feature. In higher level courses, having this feature will make it more straightforward to manage your code commits while you develop.
A modern web browser such as Google Chrome or Mozilla Firefox will be used regularly throughout this course. Internet Explorer 11 / Edge will work as well, as it supports a similar set of development tools, however due to it’s lack of plugins / addons and cross-platform support it’s not as highly recommended. All screenshots and development examples used throughout this course have been taken in Google Chrome.
Browser Developer Toolbar
Before starting this course, students should have at least a basic understanding of the Developer Tools built into a modern web browser. Typically, pressing the F12 Key (Windows) will open the bar, however there are alternate ways of opening it. For Google chrome:
This will bring up the Chrome “Developer Toolbar”, as seen below :
We will be working with many of these panels throughout the semester. A quick list of their functionality (from left to right, starting at the top left corner) is as follows:
|Element Inspector: Select an element in the page to inspect it; this will cause the Developer Tools (Devtools) to switch to the “Elements” panel and highlight the rendered source code (HTML) responsible for displaying the item. This will also cause the “Styles” panel (on the right) to highlight all current CSS applied to the element|
|Device Toolbar Toggle: Toggles the “device toolbar” on and off. This allows the developer to select a device and manually enter the pixel dimensions of the screen and scale of the page. This is useful for ensuring that the page looks correct in a variety of devices|
|Network Panel: is used to get additional insights into requested and downloaded resources. Developers can start/stop the recording of a log that tracks all resources loaded including their corresponding status code, type, time (latency), size of the resource and the initiator of the request|
|Performance Panel: enables a tool that allows developers to record and analyze all the activity in their applications as they run. It’s the best place to start investigating perceived performance issues. This is done by recording a timeline of every event that occurs after a page loads and analyzing the corresponding FPS, CPU, and network requests.|
|Security Panel: gives an overview of a page from a security standpoint including: Certificate verification (indicating whether the site has proven its identity with a TLS certificate), Transport Layer Security (TLS) connection (Note: TLS is often referred to by the name of it’s predecessor, SSL) and Subresource security (indicating whether the site loads insecure HTTP subresources – ie: “mixed content”).|
NOTE: As of Chrome 83, the "Audits" panel is now the "Lighthouse" panel (see: https://developer.chrome.com/blog/new-in-devtools-83/#lighthouse).
|Error Icon: displays the number of errors present in the “Console Pane”. To review the errors, simply switch over to the Console pane and locate the items highlighted in red.|
|Customize Icon: controls where the Developer Toolbar should be placed relative to the browser, as well as a collection of all related settings and preferences for the tool set.|
|Close Icon: closes the Developer Toolbar.|
Additionally, we will cover a number of topics surrounding the following technologies (in no particular order):
In 2015, ECMAScript 6 was released and many interesting new features were introduced, such as:
Node.js also has an expansive package ecosystem accessible via it’s Node Package Manager (NPM) utility. We will leverage this in WEB322 by experimenting with a number of popular, open-source modules including:
From the PostgreSQL site, postgresql.org:
“PostgreSQL (also known as “Postgres”) is a powerful, open source object-relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It runs on all major operating systems, including Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, macOS, Solaris, Tru64), and Windows. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation.
MongoDB is another open-source database that we will be exploring in this course. However, unlike MySQL MongoDB is classified as a “NoSQL” database and stores its data in JSON like format rather than in tables with fixed columns. The term NoSQL comes from “Not only SQL” and is intended to mean that it is a type of database system that can store data in non traditional tabular and relational format. It is because of this that NoSQL is quickly becoming a popular alternative to traditional Relational Databases (RDBMS).
We will be exploring how we can leverage NoSQL (MongoDB) to make data management simple and intuitive as well as how it compares to traditional RDBMS systems.
Powering this transaction is a protocol called HTTP (Hypertext Transfer Protocol), which defines a stateless request/response protocol that operates by exchanging messages across a reliable connection. An HTTP “client” (ie: web browser) is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP “server” is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
The HTTP Protocol itself is an Application layer protocol – that is, it essentially sits “on top” of an underlying network-level protocol such as the Transmission Control Protocol (TCP). HTTP is human-readable and extensible, which makes the protocol extremely easy to extend and to experiment with. New functionality can be introduced simply by establishing an agreement between a client and a server and specifying new “headers” – these will enable the client and server to pass additional information along with the request or the response. The payload content (ie: raw HTML) is sent in the “message body”.
Both HTTP requests and responses share a similar structure and are composed of:
HTTP requests are messages sent by the client to initiate an action on the server. Their start-line contains of three elements:
An HTTP method that describes the action to be performed:
|GET||The GET method is used to retrieve information from a specified URI (Universal Resource Identifier) and is assumed to be a safe, repeatable operation by browsers, caches and other HTTP aware components. This means that the operation must have no side effects and GET requests can be re-issued without worrying about the consequences.|
|POST||The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics. For example, POST is used for the following functions (among others): * Providing a block of data, such as the fields entered into an HTML form, to a data-handling process * Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles * Creating a new resource that has yet to be identified by the origin server. * Appending data to a resource’s existing representation(s).|
|PUT||The PUT method is used to request that server store the content included in message body at a location specified by the given URL. For example, this might be a file that will be created or replaced.|
|HEAD||The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). This method can be used for obtaining metadata about the selected representation without transferring the representation data|
|DELETE||The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server.|
|CONNECT||The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security).|
|OPTIONS||The OPTIONS method requests information about the communication options available for the target resource. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.|
|TRACE||The TRACE method requests a remote, application-level loop-back of the request message. This is typically used to echo the contents of an HTTP Request back to the requester which can be used for debugging purposes during development.|
An absolute path, optionally followed by a ‘?’ and a query string. This is the most common form, called origin form, and is used with GET, POST, HEAD, and OPTIONS methods, for example:
HTTP headers in a request follow the basic structure of any HTTP header: a case-insensitive string followed by a colon (‘:’) and a value whose structure depends upon the header. The whole header, including the value, consists of one single line, that can be quite long.
There are numerous request headers available. In a request, the headers can be divided in several groups:
The last part of a request is its body. Not all requests have one: for example, requests fetching resources (like GET or HEAD) usually don’t need any. Similarly, DELETE or OPTIONS also do not require a body.
Other requests send data in the body to the server in order to update it: this is often the case of POST requests (that can have HTML form data).
The start line of an HTTP response, called the status line, contains the following information:
A status code beginning with 1, 2, 3, 4 or 5 that provides information such as the success or failure of the request:
|1xx||Informational: Request received, continuing process.|
|2xx||Success: The action was successfully received, understood, and accepted.
For example, the 200 (Ok) status code indicates that the request has succeeded. The meaning of “success” varies depending on the HTTP method:
|3xx||Redirection: Further action must be taken in order to complete the request.
For example, The 302 (Found) status code indicates that the requested resource has been temporarily moved and the browser should issue a request to the URL supplied in the Location response header.
|4xx||Client Error: The request contains bad syntax or cannot be fulfilled.
For example, the famous 404 (Not Found) status code indicates that the server can not find requested resource, or is not willing to disclose that one exists.
|5xx||Server Error: The server failed to fulfill an apparently valid request.
For example, the 500 (Internal Server Error) status code indicates that the server encountered an unexpected error / condition that prevented it from fulfilling the request./td>
The HTTP header format for responses follow the same basic structure (a case-insensitive string followed by a colon (‘:’) and a value whose structure depends upon the type of the header. The whole header, including the value, stands in one single line)
There are numerous response headers available. In a response, the headers can be divided in several groups:
The last part of a response is the body. This is typically a single file of known length (defined by the two headers: “Content-Type” and “Content-Length”) or a single file of unknown length (encoded in chunks with the “Transfer-Encoding” header set to “chunked”. However, not all responses have a body, for example: responses with status code like 201 (Created) or 204 (No Content).
The web server plays a key role in not only servicing requests for static content like images and HTML, but also by managing the entire interaction between clients and the server, including things like: