Upload Images to AWS S3 from Node Server w/ Multer

  1. Create a bucket
    1. (Sign in to console) Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
    2. Choose Create Bucket
    3. In Bucket name,  enter a DNS-compliant name for your bucket.
    4. In Region, choose the AWS Region where you want the bucket to reside.
    5. In Bucket settings for Block Public Access, keep the values set to the defaults. They will be private for now. We will change them to public later.
    6. Choose Create bucket.

2. Get security credentials

3. Install dependencies to Node project

npm i --save aws-sdk multer multer-s3

4. Set up the file upload middleware with multer and AWS-SDK

const aws = require('aws-sdk');
const multer = require('multer');
const multerS3 = require('multer-s3');

const config = require('../config');

aws.config.update({
   secretAccessKey: config.get('AWS_SECRET_ACCESS'),
   accessKeyId: config.get('AWS_ACCESS_KEY'),
   region: 'us-east-1'
});

const s3 = new aws.S3();

const upload = multer({
   storage: multerS3({
      s3,
      bucket: 'bucket-name',
      acl: 'public-read',
      key: function (req, file, cb) {
         cb(null, Date.now().toString())
      }
   })
}).single('photo');

module.exports = upload;

In the upload middleware, we define a key value. This key serves essentially as the image’s name in AWS, differentiating images in the list in the AWS Console. We are setting the key to the date at which the image is saved.

5. Set up route to handle image requests

router.post('/image-upload', function(req, res) {
   upload(req, res, (err) => {
      if (err) {
         return res.status(422).send({errors: [{title: 'File Upload Error', detail: err.message}] });
      }

      return res.json({'imageUrl': req.file.location});
   });
});

6. Set permissions to public

7. Send request in Postman to test it

8. Check the AWS S3 console to see if a new entry is there

The Date string that we set as the key value is in the Name field.

What is a Content Delivery Network (CDN)?

A Content Delivery Network (CDN) is a system of geographically distributed servers that accelerates internet content delivery speeds.

Websites are hosted on servers. Servers are located in specific physical locations. If a user is in a location that is far from the server, they will experience load times that are longer than that of a user that is near the server. CDNs help to remedy this geographic speed inconsistency.

The CDN consists of 2 components: the origin server and the cache server(s). The origin server is, as the name suggests, the original server onto which the website was deployed. The cache servers, or edge servers, are servers around the world on which the original server’s content is duplicated.

So how does a CDN work? When a user makes a request to a website that is hosted on a server across the world, the user will receive that website’s pages from the closest cache server instead of having to wait for the long trip to the origin server.

How Content Delivery Networks Work | Beginners Guide to CDN

CDNs are most effective in speeding the delivery of content from high traffic websites with global reach. For example, YouTube has its own CDN which makes it fast for everyone all over the world. Netflix uses an algorithm to push its most viewed shows across its CDN; that’s why more popular shows load faster on the platform.

About Github Pages

Github Pages is a free solution for deploying your websites to the Internet.

There are three types of GitHub Pages sites:

  1. Project
  2. User
  3. Organization

Project sites are connected to an individual project hosted on GitHub. You can create an unlimited number of project sites. User and organization sites are connected to a specific GitHub account. You only get one user or organization site per Github account.

GitHub Pages source repositories have a recommended limit of 1GB.
GitHub Pages sites have a soft bandwidth limit of 100GB per month.
GitHub Pages sites have a soft limit of 10 builds per hour.

Github Pages publishes any static files that you push to your repository.

Create your own static files OR use a static site generator

You can create a site for yourself or your organization by creating a repository with Github Pages URL as its name and adding web content to its master branch

Benefits of Github Pages
  • Free!!
  • Can use custom domain
  • HTTPS support
  • Ingrained version control in your site
Reasons not to Use Github Pages

You probably think that Github Pages seems perfect, right? Well, it is… for certain types of websites. For small static websites, such as a portfolio website, Github Pages is a perfectly suitable option, but for more involved web applications with complex server implementation, Github Pages is rendered inadequate.

GitHub Pages sites shouldn’t be used for sensitive transactions like sending passwords or credit card numbers.

GitHub Pages is not intended for or allowed to be used as a free web hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS).

GitHub Pages does not support server-side languages such as PHP, Ruby, or Python.

Netlify

Netlify is a hosting platform that allows you to deploy static websites and front end applications (React, Angular, Vue). The free account offers a lot, but you can also get a pro account.

Netlify makes it simple to get set up and start deploying stuff by allowing you to login in through and deploy repositories from your Github, Gitlab, or Bitbucket account.

Deploying From the Browser

First, login to Netlify with one of these three version control platforms. Then, choose “New Site from Git” and on the next page choose your platform again. It will show you all of your repositories from your account. Choose the branch you want to deploy from (I recommend creating a separate deployment branch so you can still push to your master branch without it affecting your website).

Netlify CLI

Netlify also offers a CLI (command-line interface) tool that you can use to make deployments, etc. as opposed to using their simple online platform.

First, cd into your project directory and type this command: sudo npm i -g netlify-cli. Then, type netlify deploy. In your browser, Netlify CLI will ask for permission to authorize Netlify on your behalf; choose to authorize this. Then, close the window and return back to your Terminal. Answer the prompts on whether it’s a new site and which path to deploy from and you’re done! Netlify will generate a default domain for you to view your site on the Web.

Deploying a React App

We will be deploying the React App from Terminal. Make sure you already have the Netlify CLI installed globally on your system.

First, if you haven’t done so already, you want to build out your static assets using this command in your project directory: npm run build. This will put everything into a build folder. So, now if you ls your directory, you will see a folder called build.

Now you want to run the netlify deploy command (assuming you’ve already installed the CLI). Choose the build folder we created above as the path to deploy. That’s it! You’re site is deployed.

Using a Custom Domain

On the Netlify platform, choose the project which you’d like to give a custom domain. Then, press the “Domain Settings” button. Then press “Add Custom Domain.” Type in the custom domain name you’d like to use (after you’ve already boughten it, of course) and press “Add Domain.” In the Domain Registrar you use, go do any additional configuration / setup you need.

Netlify Forms

Netlify has a built-in form service called Netlify Forms that allows you to manage forms and submissions without any server-side code or JavaScript.

It’s extremely easy to implement this service in your HTML form. Just add the netlify attribute to any form and everything gets wired up automatically. Their bots find your forms by inspecting the HTML of your site before its published.

<form name="contact" netlify>
   <label>Name <input type="text" name="name" /></label>
   <button type="submit">Submit</button>
</form>

Web Hosting

When you’re developing your website, most times it will only be available on your local system. In order make it accessible to anyone, your website must be hosted on a server. A server is a powerful computer that must stay online 24/7 ready to serve up data for the websites it houses.

Servers are physically located in data centers, which are typically run and managed by different web hosting companies.

There are different types of servers with different benefits and drawbacks, thus there are different types of web hosting.

Types of Web Hosting

  1. Shared Hosting
  2. VPS Hosting
  3. Dedicated Hosting
  4. Cloud Hosting
  5. Methods of Hosting
    1. Managed Hosting
    2. Static Hosting

Shared Hosting

  • Most basic type of hosting
  • Cost-effective
  • Good for small/unpopular websites
  • Share resources w/ other websites on a single server
    • If another website on your server has a traffic spike, it could negatively affect your site’s performance
  • Easy to set up. Doesn’t require much technical knowledge

Great for beginners & small websites; those who don’t require much on-site interaction (10 – 20,000 month visits)

BlueHost

VPS Hosting

Virtual Private Server (VPS) Hosting is a middle-ground between Shared Hosting and Dedicated Hosting. Typically, when a website outgrows Shared Hosting, it will migrate to VPS Hosting.

With VPS Hosting, you are still sharing a server with other websites, but not as many. The server is broken up into smaller “virtual” servers with their own individual configurations.

This hosting benefits tech-savvy website owners because it allows them to make custom changes to their server configuration.

Pros:

  • Dedicated server resources.
  • Ability to make custom configurations to your server.
  • Higher uptime rates and faster loading speeds.
  • More cost-effective than a dedicated server.

Cons:

  • Sharing the main server with other websites.
  • Not as easy to set up as a shared server.
  • Still has limitations in terms of what you can control.

InMotion

Dedicated Hosting

With Dedicated Hosting, you will have a server that belongs to you and only you.

They’re great because…

  • Top of the line in web hosting
  • Site operates at peak performance
  • Complete technical control over server

But they also have problems such as…

  • one of the most expensive web hosting options
  • high level of tech expertise required for installation & management

Dedicated Hosting is mostly for websites that get a high-level of traffic (>100,000 monthly visits), need the highest level of security, and/or need complete control of their server configuration.

HostGator

Cloud Hosting

Cloud hosting is a newer type of web hosting. It can best be described as a hybrid version of a VPS, but more cost-effective.

Unlike traditional hosting in which your website is stored on a single server, cloud hosting plans come with multiple servers, each with its own responsibilities. If one goes down, the others help to pick up the slack, making your website more immune to server malfunctions.

Pros:

  • High security
  • Scale resources on demand & only pay for what you need
  • Less unexpected downtime

Cons:

  • Pricing isn’t always fixed
  • Unpredictable traffic can increase costs
  • Limited customization

Methods of Hosting

I couldn’t really think of the perfect word to differentiate them, so I just went with methods, but basically by “Methods of Hosting” I mean that it is not a different type of server but rather a particular way of using a server / type of web hosting.

Managed Hosting

Managed Hosting isn’t so much a type of hosting as an IT provisioning model. All managed hosting entails is that the hosting company will handle the hardware and software setup, configuration, and maintenance of your server resources. Most hosting packages you will find online are likely to be managed.

Static Hosting

Static Hosting is basically hosting for static websites. Static websites are fixed-content, HTML-based websites that display the same information to all visitors. 

Static websites and static hosting have re-emerged as an effective way of stripping the unnecessary complexities from the (simple) web development process. They are great for performance and simplicity if you don’t need anything rendered on the server.

“Cheap” Static Hosting Options: Bluehost, Hostinger, etc.

Free Static Hosting Options: Github Pages, Netlify, Amazon S3, Firebase

Which option best fits you?

Shared Hosting: The most cost-effective option for low traffic websites

VPS Hosting: websites that have outgrown shared hosting

Dedicated Hosting: Enterprise-level servers for large websites

Cloud Hosting: Works best for websites that are growing rapidly and need scalable resources

How Does the Internet Work?

The Internet is really just a giant wire. It connects every computer in the world (with Internet access) to each other. Two computers in entirely different corners of the world can communicate and transfer data back and forth through the Internet.

Some of these computers attached to the Internet have a very special job. They have to be online 24/7 ready to serve you all of the data and the files that you are requesting when you try to access websites. These computers that are doing that job are called servers. A computer that an everyday user uses to access the Internet is called a client.

Internet Service Provider (ISP): the company you pay to get access to the Internet. In the US, for example, this would be companies like Comcast & AT&T

DNS Server: responsible for translating domain names to numeric IP addresses; Domain Name System Server

IP address: postal address for your computer; every single computer connected to the Internet has an IP address

Internet Backbone: underwater cables that connect across the world that power the Internet

  1. Client requests a website (ex. https://google.com)
  2. Browser sends a message to ISP
  3. ISP relays request to a DNS Server
  4. DNS Server looks up website’s IP address in its database (216.58.210.46)
  5. DNS Server finds the IP address & sends it back to browser
  6. Now knowing the exact address, the client makes a direct request to the address through the ISP
  7. Request goes through ISP then through Internet Backbone and ends up at the Server that is located at the IP address
  8. Server sends all of the files back to client through the Internet Backbone and ISP

Type this IP address into your browser (216.58.210.46) and the browser will serve up the Google Home page.

Internet backbone - Wikipedia
The Internet Backbone’s wires literally span across the entire globe, hidden underwater