Leverage Someone Else's Code

Besides the user interface (UI), if you noticed, the web address or URL (Uniform Resource Locator) usually changes after you hit a submit button on a web form or click enter on a search bar. After you click it, let’s say you want to search information about One Piece on Google, the URL will transform to be something like 

URLs are what we interact with directly to access resources on the internet. Simply put, a URL is used to get to things online, like web pages, pictures, videos, and other files. 

URLs contain different sections. The previous URL we mentioned consists of the following parts:

It's a bit simplified, but the basic concept, from high-level application layer, is this: When you type that URL into your browser's address bar or click 

, your browser asks the web server at that address for what you want – in this case, information about "one piece." Then, the server sends back the requested information, which your browser displays on the screen.

But wait... before it gives you back a response, how does the application manage these URL changes, and who decides where it leads? This is where "the navigator" comes in. Imagine it as similar to Nami, the navigator in the "One Piece," who does map things (can't remember the last time she did anything navigator-related, but anyway). The navigator of a web app is tasked with mapping each URL to specific functions or controllers within the app.

In popular web frameworks, it’s usually called a "router”. It helps the app understand what you want to do based on the URL you're interacting with. So, when you click a link or submit a form, the navigator, or router, guides the app to the right place, ensuring that you reach the intended destination, whether it's displaying a page, processing a form, or performing any other action.

Routers aren’t just useful for users. They actually also help developers understand how an application is structured. By looking at the routes, we can quickly see the available pages or actions. This is one of my personal tricks when working with someone else’s code or exploring a legacy codebase. I start from the router, follow the paths defined there, and trace how the request flows through controllers and into the business logic. Voila!

Under the hood, the router uses routing tables to keep track which URLs match up with which handlers or controllers, sort of like a map that shows the lanes of the ocean leading to different destinations. So, when a request comes in for a particular URL, the router consults its routing table to figure out where to direct the request.

The router often takes from HTTP requests more than just the details from the URL to work well. It also wants to know information such as the method you’re using for the request (GET, POST, PUT, PATCH, DELETE), any headers you’re sending along (e.g. BEARER for authentication details), and the request body, which might have additional data the server needs to understand what you're asking for.

This simple code below sets up a basic web server in Go using gorilla/mux package. To try it out, follow these steps:

#go
package main


import (
    "fmt"
    "net/http"


    "github.com/gorilla/mux"
)


func main() {
    r := mux.NewRouter()


    // Add middleware to the router
    r.Use(LoggingMiddleware)


    // Define routes with different prefixes
    v1Router := r.PathPrefix("/api/v1").Subrouter()
    v1Router.HandleFunc("/ships", ShipsHandler).Methods("GET")


    v2Router := r.PathPrefix("/api/v2").Subrouter()
    v2Router.HandleFunc("/ships", ShipsV2Handler).Methods("GET")


    // Start the server
    http.Handle("/", r)
    fmt.Println("Server is running on port 8080")
    http.ListenAndServe(":8080", nil)
}


// Middleware function for logging
func LoggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
   	 // Perform logging actions here
   	 fmt.Println("Logging: ", r.URL.Path)


   	 // Call the next handler in the chain
   	 next.ServeHTTP(w, r)
    })
}


func ShipsHandler(w http.ResponseWriter, r *http.Request) {
    // Handle GET request for ships in v1 API
    fmt.Fprintf(w, "We are on The Going Merry Ship - v1 API")
}


func ShipsV2Handler(w http.ResponseWriter, r *http.Request) {
    // Handle GET request for ships in v2 API
    fmt.Fprintf(w, “We are on Thousand Sunny Ship - v2 API")
}

One useful feature provided by routers in web frameworks is the ability to add prefixes to group related routes together. This helps you keep your routes organized, such as putting similar pages or functionalities under the same category. You can use prefixes like 

 to group routes that handle different versions of your API. In our example above, we've defined routes for distinct versions of the API under 

 prefixes, each with its own set of routes and handler functions.

You can add more functions that have the same prefix by creating additional route handlers within the same router. Here's an example:

#go
v2Router := r.PathPrefix("/api/v2").Subrouter()
v2Router.HandleFunc("/ships", ShipsV2Handler).Methods("GET")
v2Router.HandleFunc("/arcs", ArcsV2Handler).Methods("GET")
v2Router.HandleFunc("/characters", charactersV2Handler).Methods("GET")

, and they handle requests for ships, arcs, and characters, respectively. By adding them within the 

 prefix, keeping the code organized and easy to manage.

Moreover, you can integrate middleware into the router to perform extra tasks before your request reaches the main callback function, such as authorization checks or logging action. This way, it adjusts requests before they reach their destination. Just keep in mind that middlewares are executed in sequence, so careful arrangement is crucial. In the provided code snippet, the 

 function serves as an example of middleware and is registered with the router using 

In the end, the route handler or callback function, where the core logic takes place, will receive your request and prepare the response to send back to you. For example, in our ship-related scenario, the 

 functions manage necessary tasks to display information (in real-world applications, these tasks may be much more complex). Once all operations are completed, the response is packaged and sent back to the browser.

 you'll receive the message "We are on The Going Merry Ship - v1 API", while 

 will respond with "We are on Thousand Sunny Ship - v2 API". Additionally, each request will be logged, showing the path accessed. If you try to access a resource that doesn't exist, like 

, you'll receive a "404 Page Not Found" error message.

The web address or URL usually changes after you hit a submit button on a web form. But before it gives you back a response, how does the application manage these URL changes, and who decides where it leads?

The Navigator of A Web App

Table of Contents