These frameworks use the concepts of Pre-rendering and Hydration, which represent significant advancements in the history of web development.

These frameworks leverage these concepts to create toolchains that build efficient web applications. In this article, we’ll discuss Pre-rendering and Hydration and why they are important features to use when building single-page applications.

To understand these concepts, we need to explore why they were created and what problem they are trying to solve. Let's take a look at the beginning of web applications.

Table of Contents

1. Web Development in the Past: Traditional Server-Side Rendering

   • The Downside of Traditional Server-Side Rendering

2. Traditional Server-Side Rendering vs. Single-Page Applications

   • What is a Single Page Application (SPA)?

   • Single Page Application Flow

3. Entering a New World with Pre-Rendering and Hydration

   • Why is Pre-Rendering Important?

   • What is Server Side Rendering?

   • What is Static Site Generation (SSG)?

   • What is Hydration?

   • What is Reconciliation?

   • Pre-rendering and Hydration in Action

   • A Mental Model for Hydration

   • Potential Errors when working with Pre-rendering and Hydration Frameworks

4. How does it relate to frameworks like Gatsby.js, Next.js, and Remix?

5. Moving Forward

6. Conclusion

Web Development in the Past: Traditional Server-Side Rendering

Back in the days of traditional server-side rendering, rendering and interactivity were separated. We used server-side languages like Node.js, PHP, Java, and Ruby on Rails.

Within our servers, we created views using templating languages like JSP and EJS. Views are HTML pages, and you could inject JavaScript or Java inside them to add functionality, dynamic data retrieved from database queries, and interactive segments with languages like JQuery.

The Downside of Traditional Server-Side Rendering

1. Performance Issues

• A request to the server needed to be made every time the user requested a page!

  • This meant there would be a full-page reload.

  • Complex queries could result in slower speeds.

2. Scalability Challenges

• Global Reach: A Dynamic CDN was needed to cache your dynamic files. CDNs are better suited for static content, but companies like Cloudflare created Cloudflare-Workers to help with the process.

• Upscaling Servers: If more users started using the application, there would be an increase in demand on the server. You might have needed to invest more in resources such as scaling up by adding more servers.

3. Duplicate Logic

• You may have duplicate code. For example, if you were trying to validate form fields, you'd have to validate in both the EJS file and your API endpoint.

Let's look at the code snippet below to see an example of this duplicate Logic:

Code in EJS:

<form action='/submit-form' method='POST' id="myForm">
    <label for="email">Email:</label>
    <input type="email" id="email" name="email" />
    <button type="submit">Submit</button>
</form>

<script>
    document
        .getElementById('myForm')
        .addEventListener('submit', function (event) {
            const email = document.getElementById('email').value;

            if (!email.includes('@')) {
                alert('Please enter a valid email.');
                event.preventDefault();
            }
        });
</script>

Code in Express.js:

import express from "express";
const app = express();
const path = require("path");
const port = 3000;

// To received form data
app.use(
  express.urlencoded({
    extended: true,
  }),
);

// view engine setup. Need a folder called views
app.set("views", path.join(__dirname, "views"));
app.set("view engine", "ejs");

app.get("/", (req, res) => {
  // To render the view
  res.render("index", { errors: null });
});

app.post("/submit-form", (req, res) => {
  const email = req.body.email;

  if (!email.includes("@")) {
    res.status(400).send("Invalid email.");
    return;
  }
  // Proceed with form processing
});

app.listen(port, () => {
  console.log(`Sandbox listening on port ${port}`);
});

Traditional Server-Side Rendering had significant downsides, but the introduction of single-page applications marked a new era in web development.

Traditional Server-Side Rendering vs. Single-Page Applications

What is a Single Page Application (SPA)?

A Single-page application (SPA) is a web app implementation that loads only a single web document and then updates the body content of that single document via JavaScript APIs such as Fetch when different content is to be shown. Allows users to use websites without loading whole new pages from the server. (Source: MDN)

A popular way to implement SPA is by using React. React lets you create fast applications and simplifies updating the UI more easily than DOM manipulation methods.

It offers several advantages:

• Improved User Experience

  • An SPA loads a single HTML file and dynamically updates the content as the user interacts with it. All of this is done without a full page reload.

  • An SPA can update the state of the UI easily and provide instant feedback to users based on actions taken on the app.

• Reduced Server Load

  • Most of the work is done by the browser. This reduces the load on the server!

• Better Scalability

  • The browser is now doing most of the work. We can now deploy dedicated servers focused on serving data via APIs. We can easily scale horizontally. We have the option of using servers or serverless functions like AWS lambda.

  • An SPA can be hosted on a static CDN like Netlify.

With the addition of toolchains like Vite and Create React App to automate the setup of a modern JavaScript application, engineers no longer had to worry about configuring Webpack manually.

There are some downsides to implementing SPAs. The big one is that it relies on the browser to load all the JavaScript and HTML for us. This means that on mobile devices and for people with slow internet, users may experience delays in seeing the page. Let’s examine the flow to explain this:

Single Page Application Flow

Several steps are needed for the users to finally see the HTML page.

First, the browser fetches the HTML. This initial HTML will be blank and incorrect. Why? Because the content comes from JavaScript. This means that it takes time for the browser to fetch JavaScript, load it, and execute it. Since the initial HTML is wrong, web crawlers and search engines will not find relevant content on the website and skip it.

Take a look at the below GIF. Here JavaScript is disabled on the Chrome Developer Tools. The website fails to load without JavaScript. If JavaScript is enabled but the internet connection is slow, users may see a blank page for an extended period.

This was a big problem. This led to Web Development evolving into the Pre-Rendering era.

Entering a New World with Pre-Rendering and Hydration

Why is Pre-Rendering Important?

People realized that we could generate the HTML in advance. It could be generated from our server or at build time, depending on the methods used.

Pre-rendering can be done in two ways - Server Side Rendering (SSR) or Static Site Generation (SSG)

What is Server Side Rendering?

React components are rendered on the server, and the resulting HTML is sent to the browser. This can improve SEO and initial load times. The rendering process occurs on each page request.

What is Static Site Generation (SSG)?

Static HTML pages are generated at build time. These pages can be served quickly without requiring a server to render them on the fly.

Either method is beneficial! Now the HTML that the user receives will be correct. They will see a page with content instead of a blank page as seen using Vite or Create React App.

But there is a problem: the HTML the user receives is not interactive. They cannot click on it or submit a form. How can we add interactivity to our app? By Hydrating properly🚰 🌊!

What is Hydration?

Hydration is what adds interactivity to our app. It loads the JavaScript that makes our app interactive.

In React, "hydration" is how React "attaches" to existing HTML that was already rendered by React in a server environment. During hydration, React will attempt to attach event listeners to the existing markup and take over rendering the app on the client. (Source: React Docs)

Let's see what the flow looks like for an app that uses Pre-Rendering and Hydration:

What is Reconciliation?

Reconciliation is the process by which React determines the most efficient way to update the UI in response to changes in data or component hierarchy. (Source: What is the difference between virtual and real DOM (React)?)

Reconciliation is when React figures out how to update the UI in response to changes in data or components hierarchy.

When components are rendered, a Virtual DOM is created. If there are changes in state or props, then a new Virtual DOM is created. React then uses its diff algorithm to compare the new Virtual DOM with the previous Virtual DOM to check for changes. This is reconciliation.

Based on the changes found, React is not going to update the entire UI. Instead, it will select which elements need to be updated. This article helped me understand Reconciliation.

Pre-rendering and Hydration in Action

During the Pre-rendering and Hydration flow, first, the user will see HTML with the correct content.

Then Hydration kicks in and loads JavaScript to give interactivity to the application.

Let's simulate the process of what happens if the Hydration process takes a long time (due to a slow internet connection) or if the user has JavaScript disabled.

Here is a gif where I disable JavaScript on my Portfolio. I created my portfolio using Gatsby a static-site-generation framework (it also has server-side rendering capabilities):

Even though there is no JavaScript, I can still see content on my portfolio. That’s because the user received pre-render HTML! You can see that I cannot click on the dropdown menu items or the buttons that say About Me, Projects, and Experience. That’s because the JavaScript did not load so the user cannot interact with it.

A Mental Model for Hydration

Josh Comeau created a cool mental model for Hydration. Josh calls it the “Two Pass Rendering.”

The first pass, at compile-time, produces all of the static non-personal content and leaves holes where the dynamic content will go. Then, after the React app has mounted on the user's device, a second pass stamps in all the dynamic bits that depend on the client state. (Source: The Perils of Hydration)

To Summarize:

1. The First Pass: the user sees the pre-render HTML. It contains static content, but it is missing the dynamic content.

2. The Second Pass: JavaScript starts loading and fills in the missing dynamic pieces that depend on the client state.

Potential Errors When Working with Pre-rendering and Hydration Frameworks

When working with frameworks like Next.js, the server will return static pre-render HTML, and then Hydration occurs which loads JavaScript.

But we must be careful when working with dynamic data and client-only properties. For example, take a look at this code:

Dynamic Data Error

function HydrationErrors() {
  return (
    <>
      <h1>Hydration Errors</h1>

      <div>
        <p>Today date in milliseconds is {new Date().getTime()}</p>
      </div>
    </>
  );
}

Here, the server will generate HTML with a timestamp in milliseconds. For example: 1724869161034. The Hydration process begins, and then the client loads the HTML. Time has passed and the timestamp is different, it is now 172486193750! This scenario causes the following error:

This happens because the getTime() function will generate a different timestamp.

This means that the server and client generate different HTML. The Network Tab shows us the server's response. It is a different HTML from what the client loads.

The server's response below:

The client's response below:

To Fix the Error:

function HydrationErrors() {
  const [date, setDate] = useState<number>();

  useEffect(() => {
    setDate(new Date().getTime());
  }, []);

  return (
    <>
      <h1>Hydration Errors</h1>

      <div>
        <p>Today date in milliseconds is {date}</p>
      </div>
    </>
  );
}

You can use the useEffect hook. Why would this work? Because the HTML that the server and client render will contain an empty date state variable.

Once the component mounts, the useEffect activates and adds the dynamic data from the state variable or you can use the suppressHydrationWarning flag and set it to true.

  <p suppressHydrationWarning={true}>Today date in milliseconds is {date}</p>

Using Client-Only Properties Error

Remember you cannot use window or localStorage. They do not exist on the server. Take the following example:

function HydrationErrors() {
  return (
    <>
      <div>
        {typeof window !== "undefined" && <p>This p tag will appear</p>}
      </div>
    </>
  );
}

Here, the server returns HTML with an empty <div> tag, but the client loads HTML that includes the <p> tag. This creates a HYDRATION ERROR!

This is the error that you get:

The Network Tab shows us the server's response. It is an empty <div> tag.

The server's response below:

But the client loads HTML that says "This p tag will appear".

The client's response below:

This demo was inspired by Deeecode The Web in Why Do HYDRATION ERRORS Exist? And how to solve them. He gives a great explanation of why Hydration Errors occur. I recommend watching it!

How Does it Relate to Frameworks like Gatsby.js, Next.js, and Remix?

Everything we have discussed is what all these frameworks focus on.

Static-Site Generation and Server-Side Rendering can be implemented using Gatsby.js, Next.js, and Remix. They focus on creating a pre-render HTML ready for the user to see, then initiate Hydration to add interactivity to the app.

Gatsby.js, Next.js, and Remix do not replace the concept of single-page applications – they add to the process. Take a look at this flow:

It is adding to the current SPA flow! If you did not have Pre-rendering, the process starts where the pink box begins, with an incomplete HTML.

Moving Forward

This article is meant as an introduction to pre-rendering and hydration.

Next.js first implemented these concepts with the Pages Router. Pages Router was great and introduced the world to functions like getServerSideProps, getStaticPaths, and getStaticProps to implement Static-Site Generation and Server-Side Rendering.

These implementations had their pros and cons. For example, Josh W Comeau mentioned that with getServerSideProps:

1. This strategy only works at the route level, for components at the very top of the tree. We can't do this in any component.

2. Each meta-framework came up with its own approach. Next.js has one approach, Gatsby has another, Remix has yet another. It hasn't been standardized.

3. All of our React components will always hydrate on the client, even when there's no need for them to do so.

   (Source: Making Sense of React Server Components)

The React team saw this too and created a new paradigm called React Server Components (RSC). To implement RSC, the Vercel team created the App Router. App Router still uses the concepts of pre-rendering and hydration, but it no longer uses getStaticProps, getStaticPaths, and getServerSideProps. It uses RSC and other great App Router features to implement better web applications. I recommend taking a look at App Router when you get a chance.

Conclusion

Thanks for reading this far 😃!

I learned a lot from writing this article. I started this research because I used Gatsby to create my portfolio version 4 and Next.js in my job, but I did not understand the concepts behind these frameworks and why they were created.

I made a web application to demonstrate the topics covered in the article.

• Application: https://the-nextjs-pagesrouter-guide.vercel.app/

• GitHub Repo: https://github.com/salvillalon45/the-nextjs-pagesrouter-guide

In the GitHub repo you can find the code snippets for the following:

• A page implementing getStaticProps and getStaticPaths

• A page implementing getStaticProps

• A page implementing getServerSideProps with Client Side fetching

• A page to demonstrate Hydration Errors

• Using the API directory to implement our own API routes

Resources

Here are some key learning resources I used to write this article in case you want to dig in even deeper:

• What is Hydration? by Builder

• What Exactly is REACT HYDRATION? And why does it matter? by Deeecode The Web

• How NextJS REALLY Works by Theo Browne

• Next.js - GetServerSideProps vs GetStaticProps by Morado Web Development

In each section, I will show pieces of code for you to follow along. All the code used in the tutorial is available in this GitHub Repository.

What is HTTP and What Does it Have to do with Flask?

HTTP is the protocol for websites. The internet uses it to interact and communicate with computers and servers. Let me give you an example of how you use it everyday.

When you type the name of a website in the address bar of your browser and you hit enter. What happens is that an HTTP request has been sent to a server.

For example, when I go to my address bar and type google.com, then hit enter, an HTTP request is sent to a Google Server. The Google Server receives the request and needs to figure how to interpret that request. The Google Server sends back an HTTP response that contains the information that my web browser receives. Then it displays what you asked for on a page in the browser.

How is Flask involved?

We will write code that will take care of the server side processing. Our code will receive requests. It will figure out what those requests are dealing with and what they are asking. It will also figure out what response to send to the user.

To do all this we will use Flask.

What is Flask?

_[Flask (A Python Microframework)](http://flask.pocoo.org/" rel="noopener" target="blank" title=")

It makes the process of designing a web application simpler. Flask lets us focus on what the users are requesting and what sort of response to give back.

Learn more about micro frameworks.

How Does a Flask App Work?

The code lets us run a basic web application that we can serve, as if it were a website.

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello, World!"

if __name__ == "__main__":
    app.run(debug=True)

This piece of code is stored in our main.py.

Line 1: Here we are importing the Flask module and creating a Flask web server from the Flask module.

Line 3: name means this current file. In this case, it will be main.py. This current file will represent my web application.

We are creating an instance of the Flask class and calling it app. Here we are creating a new web application.

Line 5: It represents the default page. For example, if I go to a website such as “google.com/” with nothing after the slash. Then this will be the default page of Google.

This is what the @app.route(“/”) will represent

Line 6–7: When the user goes to my website and they go to the default page (nothing after the slash), then the function below will get activated.

Line 9: When you run your Python script, Python assigns the name “main” to the script when executed.

If we import another script, the if statement will prevent other scripts from running. When we run main.py, it will change its name to main and only then will that if statement activate.

Line 10: This will run the application. Having debug=True allows possible Python errors to appear on the web page. This will help us trace the errors.

Let’s Try Running main.py

In your Terminal or Command Prompt go to the folder that contains your main.py. Then do **py main.py** or **python main.py**. In your terminal or command prompt you should see this output.

The important part is where it says Running on http://127.0.0.1:5000/.

127.0.0.1 means this local computer. If you do not know the meaning of this (like I didn’t when I started — this article is really helpful), the main idea is that 127.0.0.1 and localhost refer to this local computer.

Go to that address and you should see the following:

Congrats! You made a website with Flask!

More Fun with Flask

Earlier you saw what happened when we ran main.py with one route which was app.route(“/”).

Let’s add more routes so you can see the difference.

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello, World!"

@app.route("/salvador")
def salvador():
    return "Hello, Salvador"

if __name__ == "__main__":
    app.run(debug=True)

In lines 9–11. we added a new route, this time to /salvador.

Now run the main.py again and go to http://localhost:5000/salvador.

So far we have been returning text. Let’s make our website look nicer by adding HTML and CSS.

HTML, CSS, and Virtual Environments

HTML and Templates in Flask

First create a new HTML file. I called mine home.html.

Here is some code to get you started.

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>Flask Tutorial</title>
  </head>
  <body>
    <h1> My First Try Using Flask </h1>
    <p> Flask is Fun </p>
  </body>
</html>

Important Point To Remember

The Flask Framework looks for HTML files in a folder called templates. You need to create a templates folder and put all your HTML files in there.

Remember to always keep the main.py outside of your templates folder

Now we need to change our main.py so that we can view the HTML file we created.

from flask import Flask, render_template      

app = Flask(__name__)

@app.route("/")
def home():
    return render_template("home.html")

@app.route("/salvador")
def salvador():
    return "Hello, Salvador"

if __name__ == "__main__":
    app.run(debug=True)
  We made two new changes

Line 1: We imported render_template() method from the flask framework. render_template() looks for a template (HTML file) in the templates folder. Then it will render the template for which you ask. Learn more about render_templates() function.

Line 7: We change the return so that now it returns render_template(“home.html”). This will let us view our HTML file.

Now visit your localhost and see the changes: http://localhost:5000/.

Let’s add more pages

Let’s create an about.html inside the templates folder.

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>About Flask</title>
  </head>
  <body>
    <h1> About Flask </h1>
    <p> Flask is a micro web framework written in Python.</p>
    <p> Applications that use the Flask framework include Pinterest,
      LinkedIn, and the community web page for Flask itself.</p>
  </body>
</html>

Let’s make a change similar to what we did before to our main.py.

from flask import Flask, render_template

app = Flask(__name__)

@app.route("/")
def home():
    return render_template("home.html")

@app.route("/about)
def about():
    return render_template("about.html")

if __name__ == "__main__":
    app.run(debug=True)

We made three new changes:

Line 9: Change the route to"/about**"**.

Line 10: Change the function so it is now def about():

Line 11: Change the return so that now it returns render_template("about.html").

Now see the changes: http://localhost:5000/about.

Let’s Connect Both Pages with a Navigation

To connect both pages we can have a navigation menu on the top. We can use Flask to make the process of creating a navigation menu easier.

First, let’s create a template.html. This template.html will serve as a parent template. Our two child templates will inherit code from it.

 <!DOCTYPE html>
<html lang="en" dir="ltr">
 <head>
   <meta charset="utf-8">
   <title>Flask Parent Template</title>
   <link rel="stylesheet" href="{{ url_for('static',     filename='css/template.css') }}">
 </head>
 <body>
    <header>
      <div class="container">
        <h1 class="logo">First Web App</h1>
        <strong><nav>
          <ul class="menu">
            <li><a href="{{ url_for('home') }}">Home</a></li>
            <li><a href="{{ url_for('about') }}">About</a></li>
          </ul>
        </nav></strong>
      </div>
    </header>

    {% block content %}
    {% endblock %}

 </body>
</html>

Line 13–14: We use the function called url_for(). It accepts the name of the function as an argument. Right now we gave it the name of the function. More information on url_for() function.

The two lines with the curly brackets will be replaced by the content of home.html and about.html. This will depend on the URL in which the user is browsing.

These changes allow the child pages (home.html and about.html) to connect to the parent (template.html). This allows us to not have to copy the code for the navigation menu in the about.html and home.html.

Content of about.html:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>About Flask</title>
  </head>
  <body>
    {% extends "template.html" %}
    {% block content %}

    <h1> About Flask </h1>
    <p> Flask is a micro web framework written in Python.</p>
    <p> Applications that use the Flask framework include Pinterest,
      LinkedIn, and the community web page for Flask itself.</p>

    {% endblock %}
  </body>
</html>

Content of home.html:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>Flask Tutorial</title>
  </head>
  <body>
    {% extends "template.html" %}
    {% block content %}

    <h1> My First Try Using Flask </h1>
    <p> Flask is Fun </p>

    {% endblock %}
  </body>
</html>

Let’s try adding some CSS.

Adding CSS to Our Website

An important note to remember

In the same way as we created a folder called templates to store all our HTML templates, we need a folder called static.

In static, we will store our CSS, JavaScript, images, and other necessary files. That is why it is important that you should create a CSS folder to store your stylesheets. After you do this, your project folder should look like this:

Linking our CSS with our HTML file

Our template.html is the one that links all pages. We can insert the code here and it will be applicable to all child pages.

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>Flask Parent Template</title>

    <link rel="stylesheet" href="{{ url_for('static',    filename='css/template.css') }}">

</head>
  <body>
    <header>
      <div class="container">
        <h1 class="logo">First Web App</h1>
        <strong><nav>
          <ul class="menu">
            <li><a href="{{ url_for('home') }}">Home</a></li>
            <li><a href="{{ url_for('about') }}">About</a></li>
          </ul>
        </nav></strong>
      </div>
    </header>

{% block content %}
{% endblock %}

 </body>
</html>

Line 7: Here we are giving the path to where the template.css is located.

Now see the changes: http://localhost:5000/about.

Moving Forward with Flask and virtualenv

Now that you are familiar with using Flask, you may start using it in your future projects. One thing to always do is use virtualenv.

Why use virtualenv?

You may use Python for others projects besides web-development.

Your projects might have different versions of Python installed, different dependencies and packages.

We use virtualenv to create an isolated environment for your Python project. This means that each project can have its own dependencies regardless of what dependencies every other project has.

Getting started with virtualenv

First, run this command on your command prompt or terminal:

pip install virtualenv

Second, do the following:

virtualenv “name of virtual environment”

Here you can give a name to the environment. I usually give it a name of virtual. It will look like this: virtualenv virtual.

After setting up virtual environment, check your project folder. It should look like this. The virtual environment needs to be created in the same directory where your app files are located.

How the directory looks like

Activating the virtual environment

Now go to your terminal or command prompt. Go to the directory that contains the file called activate. The file called activate is found inside a folder called Scripts for Windows and bin for OS X and Linux.

For OS X and Linux Environment:

$ name of virtual environmnet/bin/activate

For Windows Environment:

name of virtual environment\Scripts\activate

Since I am using a Windows machine, when I activate the environment it will look like this:

You should see this at beginning of your command prompt line

The next step is to install flask on your virtual environment so that we can run the application inside our environment. Run the command:

pip install flask

Run your application and go to http://localhost:5000/

We finally made our web application. Now we want to show the whole world our project.

(More information on virtualenv can be found in the following guides on virtualenv and Flask Official Documentation)

Let’s send it to the Cloud

To show others the project we made, we will need to learn how to use Cloud Services.

Deploy Your Web Application to the Cloud

To deploy our web application to the cloud, we will use Google App Engine (Standard Environment). This is an example of a Platform as a Service (PaaS).

PaaS refers to the delivery of operating systems and associated services over the internet without downloads or installation. The approach lets customers create and deploy applications without having to invest in the underlying infrastructure (More info on PaaS check out TechTarget).

Google App Engine is a platform as a service offering that allows developers and businesses to build and run applications using Google’s advanced infrastructure — TechOpedia.

Before you Start:

You will need a Google Account. Once you create an account, go to the Google Cloud Platform Console and create a new project. Also, you need to install the Google Cloud SDK.

At the end of this tutorial your project structure will look like this.

Project Folder Structure

We will need to create three new files: app.yaml, appengine_config.py, and requirements.txt.

Content of app.yaml:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /static
  static_dir: static
- url: /.*
  script: main.app

libraries:
  - name: ssl
    version: latest

If you were to check Google’s Tutorial in the part where they talk about content of the app.yaml, it does not include the section where I wrote about libraries.

When I first attempted to deploy my simple web app, my deployment never worked. After many attempts, I learned that we needed to include the SSL library.

The SSL Library allows us to create secure connections between the client and server. Every time the user goes to our website they will need to connect to a server run by Google App Engine. We need to create a secure connection for this. (I recently learned this, so if you have a suggestions for this let me know!)

Content of appengine_config.py:

from google.appengine.ext import vendor

# Add any libraries installed in the "lib" folder.
vendor.add('lib')

Content of requirements.txt:

Flask
Werkzeug

Now inside our virtual environment (make sure your virtualenv is activated), we are going to install the new dependencies we have in requirements.txt. Run this command:

pip install -t lib -r requirements.txt

-t lib: This flag copies the libraries into a lib folder, which uploads to App Engine during deployment.

-r requirements.txt: Tells pip to install everything from requirements.txt.

Deploying the Application

To deploy the application to Google App Engine, use this command.

gcloud app deploy

I usually include — project [ID of Project]

This specifies what project you are deploying. The command will look like this:

gcloud app deploy --project [ID of Project]

The Application

Now check the URL of your application. The application will be store in the following way:

"your project id".appspot.com

My application is here: http://sal-flask-tutorial.appspot.com

Conclusion

From this tutorial, you all learned how to:

• Use the framework called Flask to use Python as a Server Side Language.

• Learned how to use HTML, CSS, and Flask to make a website.

• Learned how to create Virtual Environments using virtualenv.

• Use Google App Engine Standard Environment to deploy an application to the cloud.

What I learned

I learned three important things from this small project.

First, I learned about the difference between a static website and a web application

Static Websites:

• Means that the server is serving HTML, CSS, and JavaScript files to the client. The content of the site does not change when the user interacts with it.

Web Applications:

• A web application or dynamic website generates content based on retrieved data (most of the time is a database) that changes based on a user’s interaction with the site. In a web application, the server is responsible for querying, retrieving, and updating data. This causes web applications to be slower and more difficult to deploy than static websites for simple applications (Reddit).

Server Side and Client Side:

• I learned that a web application has two sides. The client side and the server side. The client side is what the user interacts with and the server side is where the all the information that the user inputted is processed.

Second, I learned about Cloud Services

Most of my previous projects were static websites, and to deploy them I used GitHub Pages. GitHub Pages is a free static site hosting service designed to host projects from a GitHub Repository.

When working with web applications, I could not use GitHub Pages to host them. GitHub Pages is only meant for static websites not for something dynamic like a web application that requires a server and a database. I had to use Cloud Services such as Amazon Web Services or Heroku

Third, I learned how to use Python as a Server Side Language

To create the server side of the web application we had to use a server side language. I learned that I could use the framework called Flask to use Python as the Server Side Language.

Next Steps:

You can build all sorts of things with Flask. I realized that Flask helps make the code behind the website easier to read. I have made the following applications during this summer of 2018 and I hope to make more.

Personal Projects

• A Twilio SMS App

• My Personal Website

During my internship

• Part of a project where I learned about Docker and Containers

Here is the list of resources that helped me create this tutorial:

• “App Engine — Build Scalable Web & Mobile Backends in Any Language | App Engine | Google Cloud.” Google, Google, cloud.google.com/appengine/.

• “Building a Website with Python Flask.” PythonHow, pythonhow.com/building-a-website-with-python-flask/.

• “Flask — Lecture 2 — CS50’s Web Programming with Python and JavaScript.” YouTube, 6 Feb. 2018, youtu.be/j5wysXqaIV8.

• “Getting Started with Flask on App Engine Standard Environment | App Engine Standard Environment for Python | Google Cloud.” Google, Google, cloud.google.com/appengine/docs/standard/python/getting-started/python-standard-env.

• “Installation.” Welcome | Flask (A Python Microframework), flask.pocoo.org/docs/0.12/installation/.

• “Python — Deploying Static Flask Sites for Free on Github Pages.” Reddit, www.reddit.com/r/Python/comments/1iewqt/deploying_static_flask_sites_for_free_on_github/.

• Real Python. “Python Virtual Environments: A Primer — Real Python.” Real Python, Real Python, 7 Aug. 2018, realpython.com/python-virtual-environments-a-primer/.

• “What Is Cloud Services? — Definition from WhatIs.com.” SearchITChannel, searchitchannel.techtarget.com/definition/cloud-services.

• “What Is Google App Engine (GAE)? — Definition from Techopedia.” Techopedia.com, www.techopedia.com/definition/31267/google-app-engine-gae.

If you have any suggestions or questions, feel free to leave a comment.