Week 3 - Web
Discussion
Welcome to Week 3! We'll begin this week with a discussion of last week's asynchronous content.
Review
Git - What did you learn?
- What did you learn over the last week?
- Any interesting command(s) you learned?
Pairing Practice - Boggle Solver Problem
- What language did you use?
- Tell us about your branching strategy and collaboration process.
- How did your solution work out?
Any other interesting topics from the last week?
This week
The focus on this week is on web development. We'll review the Readings & Async Content below as an initial guide to the conversation.
Reading & Async Content
We'll begin by talking about the web. We expect that everyone participating in this bootcamp has some familiarity with web development. We'll skip past the basics and focus a bit more on some details.
Networking
Every discussion of networking begins with the OSI model. It breaks down the network stack into 7 layers.
We'll focus on a few of those layers in some detail. Let's look at a simple HTTP request and response. We'll use Wireshark to debug the network traffic. As a reminder, only use tools like Wireshark on systems you own and have permission to use those tools on.
Debugging with Wireshark
In this case, we inspected local traffic and we filter on TCP Port 8080 and the HTTP protocol (as shown in the dark green bar).
We'll begin by looking at Layer 3 of the OSI model. IP or Internet Protocol is the packet layer. It's responsible for routing packets of data from one machine to another.
Layer 4, the transport later, is TCP or Transmission Control Protocol. TCP is responsible for ensuring that packets are delivered reliably and in order. and without errors. Looking at the Wireshark example below, we can see the TCP section of the network packet.
Following the TCP section, we can see the HTTP request. This is the application layer (layer 7) of the OSI model. Let's look at the HTTP section of the request packet.
The HTTP Response
Wireshark provides us a useful mechanism for exploring network traffic details, but modern browser tools make it unnecessary to use Wireshark for most debugging for web applications though it can be useful for debugging other network traffic that doesn't involve a browser.
Debugging with Dev Tools
Now let's look at the same request and response using the browser developer tools. Developer tools exist in all major browsers these days, but we'll focus on Chrome due to its popularity - the same techniques apply to other browsers.
We can open up developer tools in a few different ways. Depending on your browser and platform, there are keyboard shortcuts (i.e. Command-Option-I on MacOS), or you can right-click on the page and select "Inspect" from the context menu, finally you can use the menu to open developer tools under the "More Tools" menu or "View" > "Developer" menu.
Once you have dev tools open, you'll see several tabs. For exploring the network traffic, we'll focus on the "Network" tab. You can see the same request and response data that we saw in Wireshark.
More on Networking
In this section, we'll briefly discuss some additional networking topics. Networking is a very deep topic and we can't possibly cover everything here.
DNS or the Domain Name System is how we translate human-readable URLs into IP addresses. Name servers are the servers that store the DNS records. DNS records stored by the name servers are used to translate a URL to an IP address.
Protocols
There are a number of other protocols beyond TCP and HTTP. An alternative to TCP is UDP or User Datagram Protocol. UDP is a "fire and forget" protocol. It's faster than TCP, but it's not as reliable. Similarly there are other communication protocols beyond HTTP. For example, WebSockets are a protocol that allows for two-way communication between a client and a server. Other protocols include FTP or File Transfer Protocol, SMTP or Simple Mail Transfer Protocol, and SSH or Secure Shell.
Different protocols frequently use different ports. For example, HTTP uses port 80 and HTTPS uses port 443. FTP uses port 21. SSH uses port 22. And so on. These processes are not restricted to these ports but these are common defaults. Ports can range from 0 to 65535 while ports 0-1023 are reserved for privileged system processes.
Internet vs Intranet
Many of you may find yourself building applications that are deployed on the public internet. However, many of you may also find yourself building applications that are deployed privately for an organization on a company intranet. These different approaches come with different considerations.
For example, public facing applications may face different scalability or security considerations. While internal application may require additional DNS or network configuration.
APIs: An Overview
For an introduction to the topic of APIs, read this article.
Rest API Design
Let's talk about REST API design. There are a lot of resources out there already. We won't repeat them here, but we'll point to a few to guide the discussion and that you may want to reference in the future.
- Microsoft API Design Best Practices
- Microsoft API Design Guidelines
- Microsoft API Guidelines
- Microsoft Graph API Guidelines
- Google API Design Guide
This blog post from Ryan Pinkham at Swagger is worth giving a read as it also points to additional resources. This blog post from Stack Overflow also widely discusses the subject.
Docker & Containers
Docker is a common tool for building and deploying applications. Docker is a containerization tool. Containerization is a way to package an application with its dependencies. You can think of containers as a lightweight virtual machine. This allows for applications to be deployed in a consistent way across environments and platforms.
As with API best practices, our intent is to point you to good resources that already exist rather than recreating them. To get started with Docker, take a look at Docker's Docker 101 Tutorial.
Docker Compose is a tool shipped with Docker
for defining and running a multi-container Docker application. To use Docker Compose,
you will need to create a compose file
that defines the containers that make up your application. You can then use the
docker-compose command to start your application.
Practice
A Simple Web Service. This week we’ll work in new pairs to create a URL shortener. We’ll build a simple URL shortener with redirection. There should be the following routes:
GET /- A simple web page for interacting with the API. Use vanilla JavaScript - no fancy frameworks.- An endpoint for creating short URLs.
- An route for redirecting to the original URL.
- An endpoint to lookup a URL without redirection
The storage mechanism is up to you. Persistence isn’t required.
Docker. Run your app in Docker. Write the Dockerfile and a Docker compose file.
(optional) Extra Challenge
Let’s talk about making this more robust. Consider the following ways to make the application more robust:
- Authentication & Authorization. Add authentication to your app. Take a look at existing platforms such as Keycloak (as another container) and use JWTs.
- Logging. Add detailed logging of everything that happens in your system. Even better if your logs are automatically sent to and stored in another container (i.e. Elasticsearch or MongoDB).
- Reverse Proxy. Use a reverse proxy (such as Nginx) or write a simple one yourself. Try doing logging and authentication in the reverse proxy.