Share
Explore

Deploying the Full Stack Web Application to GitHub Pages

Lecture & Lab Notebook: Deploying a Website Using GitHub Pages
<Optional: How information moves around on a TCP IP Network: https://t2m.io/tcpip>
GitHub Pages Documentation:

Introduction to Full Stack Web Development and Deployment

Part 1: Understanding Full Stack and Web Deployment
Definition of Full Stack Development
Full Stack Development involves working with both the front-end and back-end portions of a web application.

Full Stack development is often discussed in the framework of MVC Model View Controller:

The VIEW is the front-end - rendering in html what users interact with while the back-end involves server, application, and database.
Model is the database.
Controller is the JavaScript or other language objects which encapsulate and deliver the services of the business rules and algorithms.
A big reason why Object Oriented Programming became such a popular way to program is because OBJECTS naturally fit and form good containers for Business Processes.
View is the HTML and HTTP server partition. The user connects to the Server via HTTP and the browser’s BOM interacts with the server-side programs. To understand how the view (HTML) and HTTP server interact, and how the Browser Object Model (BOM) fits into this interaction, we need to break down the process step by step. This process involves client-server communication, where the client is typically a web browser and the server is a remote machine hosting web resources and services.
info
HTTP REQUEST / RESPONSE Paradigm
.....
The HTTP request/response paradigm is a fundamental concept in web development and the primary way in which data is exchanged on the web.
This paradigm is based on a client-server communication model, where the client sends a request to the server, and the server responds.
Here's a detailed overview:
HTTP Request An HTTP request is initiated by the client (usually a web browser or a mobile app) when it needs to communicate with a server. The request consists of several components:
1. **Method**: Indicates the action to be performed. Common methods include: - `GET`: Retrieve data from the server. - `POST`: Send data to the server for processing. - `PUT`: Update data already on the server. - `DELETE`: Remove data from the server. - Other methods include `HEAD`, `OPTIONS`, `PATCH`, etc.
2. **URL/URI**: The address of the resource on the server the client wants to interact with.
3. **HTTP Version**: Specifies the HTTP version, e.g., HTTP/1.1 or HTTP/2.
4. **Headers**: Provide additional information (metadata) about the request, such as content type, language, authorization information, etc.
5. **Body**: Contains data sent to the server. It's present in requests like `POST` and `PUT`.
### HTTP Response Once the server receives and processes the request, it sends back an HTTP response. The response also has several components:
1. **Status Line**: Includes the HTTP version, status code (e.g., `200 OK`, `404 Not Found`), and a status message. 2. **Headers**: Similar to request headers, they provide metadata about the response, such as content type, content length, server information, and caching policies.
3. **Body**: The data being sent back to the client. This could be the requested HTML, JSON, XML, or binary data like images or downloads.
### Process Flow
1. **Initiation**: A user clicks a link, submits a form, or runs a JavaScript command that makes an HTTP request.
2. **Request Sent**: The client formats the HTTP request and sends it across the Internet to the server.
3. **Server Processing**: The server receives the request, interprets it, and takes the necessary action, such as querying a database or processing data.
4. **Response**: The server packages the response and sends it back to the client.
5. **Client Processing**: The client (browser) receives the response, processes it, and typically updates the web page content accordingly (in case of a `GET` request) or provides feedback to the user (in case of `POST`, `PUT`, or `DELETE`).
6. **Statelessness**: HTTP is stateless, meaning each request-response pair is independent. Servers do not retain information between different requests from the same client. To maintain state, mechanisms like cookies, sessions, or tokens are used.
### Conclusion
Understanding the HTTP request/response paradigm is crucial for web development. It forms the backbone of web interactions, defining how data is requested and received, and how servers and clients communicate in the online environment.
.....

Step 1: User Requests a Web Page

User Action: A user types a URL into their web browser or clicks on a link.
HTTP Request: The browser sends an HTTP request to the server. This request includes the URL and often other headers that provide additional information about the browser or the requested resource.

Step 2: Server Processes the Request

Server Receives Request: The HTTP server receives the request and processes it. This process might involve server-side scripts (like PHP, Python, Node.js) interacting with a database or performing other logic.
HTML Response: The server then sends back an HTML document as a response, often dynamically generated based on server-side processing.

Step 3: Browser Renders the Page

HTML Parsing: The browser receives the HTML document and parses it, constructing the Document Object Model (DOM) based on the HTML structure.
BOM Interaction: While the DOM represents the content of the web page, the BOM provides additional capabilities to interact with the browser window, like handling browser history, location, screen dimensions, etc.
Rendering: The browser renders the page to the user, applying CSS for styling and executing any JavaScript code, which can further manipulate the DOM or BOM.

Step 4: Further Interaction (Client-Side JavaScript and BOM)

User Interactions: When a user interacts with the page (like clicking a button or filling out a form), client-side JavaScript can handle these events.
AJAX Requests: JavaScript can send asynchronous HTTP requests (AJAX) to the server without reloading the entire page. This is where the BOM's XMLHttpRequest or the fetch API comes into play.
Server Processing: The server receives these AJAX requests, processes them, and sends back data (often in JSON format).

Step 5: Dynamic Updates (DOM Manipulation)

Updating the DOM: The JavaScript on the client-side then uses this data to dynamically update the DOM, altering the content or appearance of the webpage without a full page reload. This interaction is often used in single-page applications (SPAs) and other dynamic websites.

Key Points:

HTTP as the Communication Protocol: The foundational role of HTTP in requests and responses between the client and server.
Separation of Concerns: HTML/CSS for structure and styling (view), JavaScript for client-side behavior, and server-side languages for backend processing.
BOM for Browser Interaction: JavaScript's use of the BOM to interact with the browser, separate from the page content.

Conclusion:

The interaction between the view (HTML), the HTTP server, and the browser’s BOM is a coordinated dance where:
The server provides content and services.
The browser requests and displays this content.
JavaScript, both client-side and server-side, adds interactivity and dynamism, with the BOM allowing additional control over the browser environment.

megaphone

Here we will be focusing on the “FAT CLIENT” topology in which everything rules and lives in the BOM. In later classes we will see how to do this with server-side JavaScript:

Objective: Demonstrate how to create a simple single-page application (SPA) with two sections:
A form on the first "page" and a display area on the second "page". The entered data in the form is conveyed to the display area using HTML, CSS, and ECMAScript 6 compliant JavaScript.
Objective: Create a single-page (local fat client) application where a user can input data in a form on the first page and see the results displayed on the second page.

This lab demonstrates a basic SPA functionality using HTML, CSS, and ES6 JavaScript, following best practices like arrow functions, `let` and `const` for variable declarations, and event listener usage. This example can be expanded upon for more complex applications.

megaphone

Here is an example of a Client-Side approach to constructing a simple Single Page Application:

Consider for your Assignment which are the “source” pages of user provided data, and where the data plumbing needs to be done to “delivery truck” that data to the receiving webpage. Draw pictures and diagrams to help visualize this.
To pass data between pages using query parameters in a client-side approach with ECMAScript 6, you would typically:
Capture Form Data and Append to URL on Submission:
Use an event listener on the form submission to capture the data and construct a URL with query parameters.
Read the Query Parameters on the Target Page:
Parse the URL on the target page to extract the query parameters.
Here's an ECMAScript 6 compliant example to illustrate this process:
image.png
The `index.html` and `details.html` files demonstrate proper ECMAScript 6 (ES6) best practices in the following ways:
1. **Arrow Function Syntax**: Both files use arrow functions in their event listeners (`(event) => {}`). This ES6 feature provides a more concise and cleaner way to write functions compared to traditional function expressions.
2. **Use of `const`**: In `index.html`, variables `username` and `secretcode` are declared using `const`, aligning with ES6 best practices. `const` is used for variables that should not be reassigned, enhancing code readability and reducing potential errors.
3. **`document.addEventListener`**: Both files utilize `document.addEventListener` for handling events. In `index.html`, it captures the form submission, while in `details.html`, it ensures the code runs after the DOM is fully loaded. This approach is more flexible and powerful than traditional inline event handling.
These practices result in cleaner, more efficient code, and better alignment with modern JavaScript standards.

Explanation:

First Page JavaScript: Captures the form data and redirects to the details.html page, appending the username as a query parameter.
Second Page JavaScript: Runs when the DOM content is fully loaded, extracts the query parameter, and displays the username.
encodeURIComponent is used to ensure the username is URL-encoded, handling any special characters correctly.
URLSearchParams is a built-in browser API used for parsing the query string.
Remember, this approach exposes the data in the URL, so it's not suitable for sensitive information. For more complex or secure data handling, consider server-side processing or other client-side storage options like localStorage.


Client and Server Architecture:

Client
The front-end part, which runs on the user's browser. It includes everything the user experiences directly: HTML, CSS, and frontend JavaScript.
Server
The back-end part, which runs on a remote machine. It handles HTTP requests, processes data, and sends it back to the client.

Part 2: Deploying a Website

Overview of Deployment

Deployment is the process of putting a website on the Internet. Create a URL accessible anywhere on the Internet.

It involves uploading your site's files to a server: For now: we will use GITHUB as a STORE for our assets (files).

And we will use GITHUB Pages as the HTTP Server to provide a URL to portal access to our HTML pages.

Introduction to GitHub Pages

What is GitHub Pages?
GitHub Pages is a feature of GitHub that lets you host static websites from GitHub repositories and make them publicly available or even privately accessible within your team and organization.

GITHUB is a free hosting service provided by GitHub that allows you to host static websites directly from your GitHub repository.
Why use GitHub Pages?
Ideal for educational purposes, personal projects, and portfolios.
It offers free hosting for static websites and an easy-to-use deployment process.
(Note: GitHub Pages does not provide the services of an Application Server).

image.png

Lab: Deploying Your Website with GitHub Pages

Objective: By the end of this lab, students will know how to deploy a static website using GitHub Pages.
Tools Required: - GitHub Account : Student Activity: Let’s set this up.
- Git installed on your computer — We will install GitHub Desktop.
- Basic knowledge of Git (commit, push)
### Lab Exercise:
#### Part 1: Prepare Your Website for Deployment
1. **Create a Static Website**:
Verify the name of the directory your project is in: You will be making a GIT REPOSITORY in that directory
- If you already have a static site (HTML, CSS, JavaScript), ensure it's ready for deployment. - Make sure all links and resources are relative paths, not absolute.
2. **Initialize a Git Repository** (if not already done): ```bash

git init git add . git commit -m "Initial commit"

We will start from here: Part 2: Create a GitHub Repository

1. Create a New Repository on GitHub: - Log in to your GitHub account. - Create a new repository for your project.
image.png

2. Link Your Local Repository to GitHub:

Note that we can do this because we have installed a GIT CLIENT on the Desktop. ```bash git remote add origin <REMOTE_URL>
image.png
3. Push Your Code to GitHub: ```bash git push -u origin master
Note that for this to work, we must do a fairly complicated procedure to authenticate to GITHUB from the command line.
For phase 1 of our investigation into GIT Pages, we will just upload the files for now.
```

Part 3: Deploying with GitHub Pages

1. Go to Your Repository on GitHub: - Navigate to the repository where your project is pushed.

Re-upload, add new files as necessary.

Upload your files as necessary:
image.png

2. Enable GitHub Pages: ​ - Go to 'Settings' in your repository.

image.png
- Scroll down to the "GitHub Pages" section.
image.png
- Select the branch you want to deploy (usually `main’).
image.png

- Click 'Save'.

image.png

3. Access Your Published Site: - GitHub will provide a URL where your live site is accessible. - It might take a few minutes for the site to go live.

image.png
Updating your content?
image.png
Conclusion:
Congratulations! Your website is now live on the Internet using GitHub Pages.
This is a significant first step in understanding web deployment and the principles of full-stack development.

Further Exploration:

- Explore how to use custom domains with GitHub Pages. - Learn more about server-side programming for dynamic websites. - Experiment with more advanced features of Git and GitHub.

This lecture and lab provide a comprehensive overview and hands-on experience with deploying a static website using GitHub Pages, an important skill for budding full-stack developers.

info

Deployment Checklist:


Deploying Your Magic Shoppe Shopping Cart App to GitHub Pages: Step-by-Step Checklist
Pre-Requisites: - Basic knowledge of HTML, CSS, and JavaScript. - A completed Magic Shoppe Shopping Cart App (or any static website). - A GitHub account. If you don't have one, [sign up for GitHub](https://github.com/join).
#### Step-by-Step Guide:
1. **Install Git**: If you can run the git command at the command line, you have GIT installed:
image.png
If Git is not installed on your computer, [download and install Git](https://git-scm.com/downloads). - Check the installation by opening your terminal or command prompt and running `git --version`.
2. Create a Local Git Repository: - Open the terminal or command prompt. - Navigate to your project directory using `cd path/to/your/project`.
NOTE: You must be familiar with basic shell commands:
Initialize a Git repository: ``` git init ```
3. **Prepare Your Project**: - Ensure that your project's main HTML file is named `index.html`. - Check that all file paths (to CSS, JavaScript, images) are relative and not absolute.
4. **Add Your Project to the Repository**: - Add all files to the staging area: ``` git add . ``` - Commit the files to the repository: ``` git commit -m "Initial commit of Magic Shoppe Shopping Cart App" ```
5. **Create a GitHub Repository**: - Log in to your GitHub account. - Go to the [Repositories tab](https://github.com/new) and click 'New' to create a new repository. - Name your repository and provide a brief description. - Keep the repository public. - Do not initialize with a README, .gitignore, or license (since your project already exists locally). - Click 'Create repository'.
6. Link Your Local Repository to GitHub - In your GitHub repository, find the "Quick setup" section. - Copy the URL provided under "…or push an existing repository from the command line". - In your terminal, link your local repository to GitHub with: ``` git remote add origin YOUR_REPOSITORY_URL ``` - Replace `YOUR_REPOSITORY_URL` with the URL you copied.
7. **Push Your Code to GitHub**: - Push your local code to GitHub with: ``` git push -u origin master ```
8. Enable GitHub Pages for Your Repository - On GitHub, navigate to your repository. - Go to 'Settings'. - Scroll down to the "GitHub Pages" section. - Under "Source", select the branch to deploy (usually `master` or `main`). - Click 'Save'.
9. Access Your Published Site: - Once GitHub Pages is enabled, scroll back to the "GitHub Pages" section in settings. - Find the URL provided for your deployed site. It should look like `https://[username].github.io/[repository-name]/`. - Click on the link to view your deployed Magic Shoppe Shopping Cart App. - Note: It might take a few minutes for the site to be accessible.
10. Your Magic Shoppe Shopping Cart App is now live and can be accessed by anyone on the Internet.
Additional Tips: - Regularly update your live site with changes by committing to your local repository and pushing to GitHub. - Explore custom domains or advanced GitHub Pages features for a more personalized deployment.


Part 3: Further considerations: How to Deploy your Web Site Assets for maximal benefit, in terms of the Business Domain you are serving:
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.