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 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.

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

When I first started coding, especially for making websites, about two and a half years ago, I thought everyone wrote their code completely from scratch using plain HTML, CSS, vanilla Javascript, and pure PHP. However, as I spent more time learning and gaining experience, I came to understand that’s not often the way things are typically done.

For many of you, it may seems quite obvious, especially when you think about long-standing tools like WordPress, which has been offering pre-built functionalities and customizable templates ever since. Nowadays, there are even convenience options with no-code (which actually means someone else's code) technologies like Wix, making it easier for us to build websites and applications without any coding knowledge.

Those tools can be handy for creating basic websites, such as blog or company profile sites. Yet, for developers aiming to build more complex websites, it’s crucial to construct projects that are both easy to manage and can adapt. This often involves using a variety of frameworks and libraries—or even boilerplates—created by other developers, that provide more detailed solutions for specific tasks.

I’ve got my hands dirty on some popular frameworks, including but not limited to Laravel, Express, and Next.js. These all come with a bunch of tools and guidelines to follow that help in structuring and organizing the development process. Express, for example, simplifies web servers setup in Node.js without the need to write all the code required to handle HTTP requests, manage routes, and handle responses at a low-level.

I also have made use of packages, such as Spatie, Sanctum, React, JWT, Socket.io, and multiple ORMs (Object Relational Mapping), which offer specific functionalities or parts that I add into my projects. For instance, JWT (JSON Web Token) helps me handle authentication and security within the project by providing a specific tool for generating, verifying, and managing authentication tokens.

Using frameworks and libraries in software development comes with both advantages and disadvantages. Some people prefer to avoid those dependencies altogether, while others do acrobatics with them enthusiastically.

Some developers prefer not to use dependencies due to concerns about unnecessary complexity that could slow down performance or make the project contain a huge amount of extra code that isn’t really needed. They also worry about the potential risk of security issues, especially in older versions of the tools that may be used on their project. Other concerns involve getting stuck using one particular external code that lead to difficulties in maintaining or evolving their projects over time.

On the flip side, since there is no need to reinvent the wheel, many developers find libraries and frameworks to be useful tools that can significantly speed up development time and establish a solid foundation. Additionally, they often come with communities of developers who offer support and advice for their issues. For beginners like us, utilizing them can be particularly beneficial, as they provide a structured learning environment that helps us understand coding practices better.

Whether or not to leverage someone else’s code to your projects depends on the specific requirements of each development. Whatever works for your needs. 

For those considering using it and minimizing drawbacks, here is a tip from me: taking the time to 

read the documentation thoroughly a.k.a RTFM

, instead of simply just copy-pasting code blindly; can save us from problems later on. There have been times where I spent many hours coding and debugging, only to find out that the solution was clearly outlined in the documentation.

Blog:

The Navigator of A Web App

Leverage Someone Else's Code