Details of Deployment

So you build an isomorphic JavaScript web application. You use React.js with Flux architecture to create your user interface (UI) and manage state throughout your application’s front end. You build a Node.js server using Express.js. This server properly routes requests and responds to them accordingly. A need to store data arises so you implement a database in MongoDB using an object document mapper (ODM) like Mongoose to model your application data. You then deploy your application using Heroku and purchase a domain name. Users can visit your web application by typing its URL into their favorite web browser. Nice work!

If you are familiar with the process outlined above or just generally familiar with full stack web development read on. This article will provide you with the answers to the following questions:

  • How do users actually access this deployed application1?
  • Where does your application live?
  • How is your application transferred from a far off server to a user’s computer?

The Cast

To begin, let’s introduce some of the major players in this story. A web client is software. Its function is to translate user input into requests made to another computer called a web server. Web browsers (like Chrome, Safari or Firefox) are web clients. The computer that client software runs on has a unique numerical identifier attached to it called an Internet Protocol (IP) Address. Every computer on the Internet (this includes every client and server) has an IP address. IP addresses allow computers using the Internet Protocol to identify one another. The Internet Protocol is the set of rules for how computers connected to the Internet should route data to the computer they are sending data to.

A server is a piece of hardware much like an ordinary computer, but without a screen and a keyboard attached. The software running on a server are called server processes. On a web server lives the simple application described at the beginning of this article. You can think of your application being the server process on the server it lives on. A web server is a type of server that stores and delivers web pages to clients when a client asks for it. A web server "listens" for requests originating from some client.

The Server-Client Model: A Love Story

The server you built using Express and Node handles requests made by a client. The server listens for requests and responds accordingly. This relationship - between a client that requests resources and the server that provides these resources - can be described by the client-server model. This model is based on a network architectural specification called Representational State Transfer (REST). REST can be thought of as a set of rules for how a network is organized. It should be noted that REST is just one set of rules for a how a computer network can be organized - others exist too. A network whose organization follows these rules is considered RESTful. The Internet abides by a RESTful specification. A RESTful network follows these general constraints2:

  1. Statelessness: This refers to the way requests are made. A request made by a client to a server has all necessary detail in order for the server to completely understand and subsequently fulfill that request. No prior knowledge is required by a server to fulfill a client’s request.
  2. Client-Server Model: The network follows the client-server model: clients ask for resources from a web server and a web server provides these resources.
  3. Uniform resource: Each part in a RESTful system interacts with every other part of the system in a standardized way. Requests are “written” in a way that is understandable by any server in the network.

How is the client-server model and REST carried out in practice? The answer to this question can be mostly answered by understanding the HyperText Transfer Protocol (HTTP), the Transmission Control Protocol (TCP) and the Internet Protocol (IP). HTTP is a specification for how clients should request information from servers. It is how a web browser specifies what resources it wants from, or wants to add to, a server. HTTP utilizes TCP and IP. You can think of HTTP being an abstraction of how data is transferred between computers in a network and TCP/IP as describing the details for how data is actually transferred. TCP is the set of rules for how information should be transferred over the Internet. TCP specifies that data transferred over the internet must be broken up into packets. It also specifies how these packets are reassembled into their original message once they have all reached the intended IP address. A packet is a chunk of information of some specified size - size here refers to the number of bytes that represent a packet - that can be transferred over a network. The size of a packet is dictated partly by the physical limitations of the communication network being used. IP is responsible for specifying the path by which a packet of information should travel through the Internet so it reaches its intended recipient.

How Sally Accesses Your Application

When a user wants to visit your deployed application they enter its Uniform Resource Locator (URL) into their favorite search engine. Below is an example of a URL. A URL identifies a particular resource on the web. It specifies the protocol (like http) in which the request is being made, a domain name which is used to find the IP address of the web server you are requesting resources from, and includes the name of the files or resources you are requesting.

To reiterate, entering a URL into a search engine initiates a request for some resource that exists on some remote server. The response your browser gets after making a request is the IP address of the server hosting the resource you are requesting, as well as the port number of the server that will handle your request. A is a specific part of a server that will process a specific request. You can think of it as the software especially suited to handle the request being made. Below is an example of such a response.

Your browser uses this IP address and port number to connect to this server and make HTTP requests for any resources it wants. It then loads all the resources requested onto your machine and constructs the DOM. Your application now appears on a user’s machine.

Coda

So there you have it. After reading this you should understand the basics of how resources are transferred over the Internet. Obviously, there are many details not mentioned here like HTTP verbs, the DNS and ISP’s.

Further Reading

For more information on this broad topic see:

  • this three part article on REST, HTTP and the structure of the Internet
  • Programming JavaScript Applications by Eric Elliot. An online version of the book can be found here.
  • this resource is good for those wanting a particularly in-depth treatment of the subject matter

1. Everything discussed in this article applies to a simple application with relatively few users. Once an application is more widely used additional engineering concerns arise.
2. There are more constraints to a RESTful network. I am only listing three of them.


Interested in learning more about JavaScript? Visit us at http://www.makersquare.com/.