DEV Community: Margaret Apiyo

A Practical Guide to API Types: REST, GraphQL, gRPC, SOAP, and WebSocket.

Margaret Apiyo — Fri, 17 Jul 2026 18:33:37 +0000

A Practical Guide to API Types and When to Actually Use Each One

Every job posting says "experience with APIs," but that phrase covers a lot of ground. REST, GraphQL, gRPC, SOAP, WebSocket, they're all "APIs," yet they solve different problems and make different trade-offs. I've shipped code against all five, and picking the wrong one for a project is the kind of mistake you don't feel until six months later when you're stuck maintaining it.

This post covers what an API actually is, then breaks down the major styles you'll run into on the job and how each one works, what a request/response actually looks like, and when you'd reach for it over the others.

What Is an API

An API (Application Programming Interface) is a interface that allows one piece of software to communicate to another without either side needing to know how the other one is implemented internally. You send a request in an conventional format, you get a response back in an conventional format, done.

The differences between API styles come down to a handful of design decisions:

What does a request/response actually look like on the wire?
Is communication one-shot (request → response) or ongoing (a persistent connection)?
How strict is the interface between client and server?
How is data structured,documents,remote procedure calls, or something else?

Let's go through the major styles.

1. REST (Representational State Transfer)

REST is quite common API that most people interact with either knowingly or unknowingly. It's not a protocol like HTTP or TCP,it's an architectural style, a set of conventions for using HTTP the way it was originally intended.

How it works:

Everything is a resource, addressed by a URL (/users/42, /orders/107/items)
You interact with resources using standard HTTP methods: GET (read), POST (create), PUT/PATCH (update), DELETE (remove)
Responses are usually JSON (though XML is technically fine too)
REST is meant to be stateless ,each request carries everything the server needs; the server doesn't remember previous requests

Example:

GET /api/users/42 HTTP/1.1
Host: example.com

Response:
{
  "id": 42,
  "name": "Apiyo Okafor",
  "email": "apiyo@example.com"
}

Creating a resource looks similar, just with a different verb and a body:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Apiyo Okafor",
  "email": "apiyo@example.com"
}

Strengths:

Simple, widely understood, huge tooling ecosystem
Plays nicely with HTTP caching, load balancers, and CDNs
Easy to debug with just a browser or curl

Weaknesses:

Over-fetching / under-fetching: GET /users/42 might return fields you don't need, and you might need three more requests to get related data
No built-in strict schema,contracts often live only in documentation (or Swagger/OpenAPI specs)
Versioning (/v1/, /v2/) can get messy over time

Best for: public APIs, CRUD-heavy applications, anything where cacheability and simplicity matter more than flexibility.

2. GraphQL

GraphQL came out of Facebook, built specifically to fix REST's over-fetching and under-fetching problem. Instead of many fixed endpoints, you get a single endpoint, and the client describes exactly the shape of data it wants back.

How it works:

One endpoint, typically POST /graphql
The client sends a query describing the fields it needs, and the server returns exactly that, no more, no less
A strongly typed schema defines every possible query, mutation, and type up front

Example:

query {
  user(id: 42) {
    name
    orders(last: 3) {
      total
      date
    }
  }
}

This single request replaces what might be two or three REST calls, and it returns only the fields listed. Writes work through mutations, which look similar:

mutation {
  updateUser(id: 42, input: { name: "Apiyo N. Okafor" }) {
    id
    name
  }
}

Strengths:

Client controls exactly what data comes back,no over-fetching
One request can pull nested/related data in one round trip
Strong typing means better tooling (autocomplete, validation, introspection)

Weaknesses:

Caching is harder since there's no URL-per-resource for HTTP caches to key off
More complex to set up on the server (resolvers, schema design, query cost limits)
A single expensive/deeply nested query can strain the server if not guarded against

Best for: applications with complex, nested, or highly variable data needs, think mobile apps pulling data from many related sources, or frontends built by teams who don't want to wait on backend changes for every new field.

3. gRPC (Google Remote Procedure Call)

gRPC works differently from both. Instead of resources (REST) or queries (GraphQL), you're calling a function on another machine, and it feels almost like calling a local function.

How it works:

Built on HTTP/2, using Protocol Buffers (protobuf),a compact binary format instead of JSON
You define a .proto file describing services and message types, and gRPC generates client/server code in your language of choice
Supports streaming: client-streaming, server-streaming, and full bidirectional streaming, not just request/response

Example (.proto definition):

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int32 id = 1;
}

Once you generate code from that .proto file, calling it from Python looks like a normal function call:

response = user_service_stub.GetUser(UserRequest(id=42))
print(response.name)

No manual JSON parsing, no guessing field names,the client is generated straight from the contract.

Strengths:

Very fast and bandwidth-efficient (binary format, HTTP/2 multiplexing)
Native streaming support,great for real-time or high-throughput data
Strict, generated contracts reduce integration bugs between services

Weaknesses:

Not human-readable on the wire and it is harder to debug without tooling
Poor browser support natively (needs gRPC-Web + a proxy)
Steeper learning curve, less friendly for public-facing APIs

Best for: internal microservice-to-microservice communication where speed and strict contracts matter more than human readability.

4. SOAP (Simple Object Access Protocol)

SOAP is the oldest style on this list, and you won't see it much in modern startups — but it's still running plenty of banking, insurance, and government systems, so it's worth knowing.

How it works:

Messages are strictly formatted XML, wrapped in an "envelope"
Comes with a rigid contract called WSDL (Web Services Description Language) that precisely defines every operation, input, and output
Includes built-in standards for security (WS-Security), transactions, and reliable messaging

Example:

<soap:Envelope>
  <soap:Body>
    <GetUser>
      <UserId>42</UserId>
    </GetUser>
  </soap:Body>
</soap:Envelope>

Strengths:

Extremely strict, well-defined contracts — great for formal enterprise integrations
Built-in support for security and transactional guarantees that heavily regulated industries need
Protocol-agnostic (can technically run over more than just HTTP)

Weaknesses:

Verbose XML payloads — slower and heavier than JSON or binary alternatives
Rigid and ceremonial; slower to develop against than REST or GraphQL
Considered legacy by most modern web/mobile developers

Best for: enterprise systems, financial services, healthcare, and other domains where formal contracts, security standards, and reliability guarantees are non-negotiable.

5. WebSocket

Everything above is request-then-response. WebSocket breaks that pattern — it opens a persistent, two-way connection between client and server, and either side can send a message whenever it wants, without waiting to be asked.

How it works:

Starts as an HTTP request that "upgrades" to a WebSocket connection
After the handshake, both client and server can push messages over the same open connection, with much lower overhead than repeated HTTP requests

Example (JavaScript client):

const socket = new WebSocket("wss://example.com/chat");

socket.onmessage = (event) => {
  console.log("New message:", event.data);
};

socket.send("Hello, server!");

Strengths:

True real-time, bidirectional communication
Low overhead once the connection is open,no repeated HTTP headers per message
Ideal for anything that needs to "push" data without the client asking

Weaknesses:

Not resource-oriented — doesn't fit naturally with typical CRUD operations
Harder to scale/load-balance (connections are stateful and long-lived)
Overkill for anything that isn't genuinely real-time

Best for: chat apps, live dashboards, multiplayer games, collaborative editing tools, stock tickers, anywhere the server needs to talk first.

Quick Comparison

Style	Data Format	Communication	Best For
REST	JSON/XML	Request/response	General-purpose, public APIs
GraphQL	JSON	Request/response (flexible shape)	Complex, nested, client-driven data needs
gRPC	Protobuf (binary)	Request/response + streaming	Internal microservices, high performance
SOAP	XML	Request/response	Enterprise, regulated industries
WebSocket	Any (often JSON)	Persistent, bidirectional	Real-time, push-based apps

How to Choose

A few rules of thumb that tend to hold up in practice:

Building a public API for third parties? Start with REST. It's the lowest common denominator everyone understands.
Frontend team constantly needs new field combinations and you're tired of versioning endpoints? GraphQL earns its complexity.
Talking service-to-service inside your own infrastructure, and performance matters? gRPC.
Integrating with a bank, hospital system, or government agency? You'll probably be handed a WSDL file and told to use SOAP and that's fine, it's built for that world.
Need the server to push updates the moment something happens? WebSocket (or a managed alternative like Server-Sent Events for one-directional push).

None of these is objectively "better." They're solving for different constraints, and picking one is really about matching the constraint you actually have,public consumers, internal services, complex nested data, regulatory requirements, or real-time updates.

Wrapping up

You'll end up using more than one of these in a typical career, sometimes in the same project,REST for a public-facing API, gRPC between internal services, WebSocket for the live notification feed. Knowing why each one exists, not just the syntax, is what makes it easy to pick the right one instead of defaulting to whatever you used last time.

What do you reach for most often, and why? Curious to hear what other people are running in production.

Go Web Frameworks: Why I Chose Gin Over Fiber for a Real-Time Geo-App

Margaret Apiyo — Mon, 06 Jul 2026 12:38:13 +0000

If you spend five minutes browsing the Go ecosystem for a web framework, you will inevitably run into the classic showdown: Gin vs. Fiber.If you look purely at tech benchmarks, Fiber looks like the undisputed king. It boasts mind-boggling numbers of requests-per-second and near-zero memory allocations. It looks like a no-brainer, right?Well, I am currently architecting a real-time security alert mobile app based in Kenya. The app tracks user GPS locations and triggers physical hardware vibrations when they approach crime hotspots or road accident black spots.When dealing with real-world mobile networks, geospatial data, and background processing, I quickly realized that raw framework benchmarks are a lie.Here is a deep dive into why I chose Gin, the engineering trade-offs of both frameworks, and why Fiber's speed comes with a hidden cost. The Contenders under the HoodTo understand why they perform differently, we have to look at their foundational engines.

Gin: The Battle-Tested Veteran

Gin has been a staple of the Go community since 2014. It is built directly on top of Go's native standard library (net/http) but uses an incredibly fast Radix Tree-based router (httprouter).Philosophy: Stay close to idiomatic Go, maintain maximum compatibility, and remain completely predictable.

Fiber: The Speed Demon

Fiber is a newer framework heavily inspired by Node.js’s Express.js. To achieve its speed, it makes a radical architectural choice: it completely ditches Go’s standard library. Instead, it runs on top of fasthttp, an engine written from scratch for hyper-performance.Philosophy: Minimize memory allocations at all costs and give JavaScript developers a familiar syntax.

The Hidden Trap: Why Fiber is Fast (and Dangerous)

Fiber’s incredible benchmark speeds come from a feature called Request/Response Pooling.Instead of allocating fresh memory for every incoming network request, Fiber grabs a block of memory from a recycled pool, overwrites it with the new request data, uses it, and flushes it for the next request.This works beautifully for basic synchronous APIs. But in Go, we love asynchronous concurrency using goroutines. Look at this common design pattern:

go
app.Post("/api/v1/location", func(c *fiber.Ctx) error {
    req := new(LocationRequest)
    c.BodyParser(req)

    // Spin up a background routine to log location to a database
    go func() {
        // CRASH/BUG: By the time this runs, Fiber has already recycled 
        // the memory pool. 'req' now contains data from a completely different user!
        db.Save(req.Latitude, req.Longitude) 
    }()

    return c.SendStatus(200)
})

If you pass a request pointer into a background thread in Fiber, the data can be silently overwritten by another user's request a millisecond later. This leads to silent, terrifying data corruption that is a nightmare to debug.To fix this in Fiber, you have to write verbose code to explicitly "deep copy" every variable out of the context. In Gin, because it allocates clean memory per request natively, this background routine is completely safe out of the box.Real-World Constraints:

Why Gin Won My Geo-Project

For my security alert application, three practical factors completely outweighed Fiber's benchmark speeds:

Seamless Geospatial Ecosystem To index coordinates of dangerous zones like Waiyaki Way or the Kasarani-GSU stretch, I need to hook my Go backend into massive geospatial libraries like Google's S2 or Uber's H3 spatial indexers. Because Gin uses the standard net/http stack, every major database driver (PostGIS, Redis Geo) and spatial tool integrates with zero friction. Fiber often requires messy wrappers or custom adapters.
Native HTTP/2 Support for Moving Devices
When a user is moving fast on a highway or riding a Matatu, their mobile data connection constantly jumps between cellular towers, fluctuating between 3G, 4G, and 5G.Gin supports HTTP/2 natively. This allows multiplexing, keeping a stable single connection open even through network drops.Fiber (fasthttp) does not natively support HTTP/2. To get it to work for a mobile app, you are forced to deploy and configure a reverse proxy like Nginx or Envoy in front of it just to translate the traffic.
Binary Payloads (Protobuf/gRPC)
To save my users' expensive mobile data bundles, I don't want to transmit heavy, wordy JSON payloads over the network. I want to compress spatial coordinates into tiny, lightweight binary files using Protocol Buffers. Gin provides native, one-line support for rendering binary protobuf formats (c.ProtoBuf()).

The Ultimate Decision Matrix

So, when should you actually use what?

Choose Gin If...	Choose Fiber If...
Your team writes standard, idiomatic Go.	Your team comes from a heavy Node.js/Express.js background.
You rely heavily on asynchronous background goroutines.	Your routes are strictly synchronous (Fetch -> Save -> Respond).
You need native HTTP/2, HTTP/3, or Protobuf support.	You are building an IoT sensor ping server or an Ad-Tech bidder.
Enterprise data safety and stability are your top priorities.	You need to squeeze every ounce of raw requests-per-second speed.

Final Thoughts

In 95% of real-world web applications, the framework engine is never the bottleneck. Your database query execution times, network latencies, and file operations take up 99% of your application's timeline.While Fiber is an incredible feat of engineering for ultra-high-throughput, synchronous micro-services, Gin remains the pragmatic, safe, and stable choice for complex production systems where data integrity cannot be compromised.

What framework are you using for your current Go stack? Have you ever run into memory pooling bugs in production? Let's discuss in the comments!

Maps vs Structs in Go: Making the Right Choice for Your Data

Margaret Apiyo — Thu, 25 Jun 2026 08:28:29 +0000

__
Choosing between maps and structs is one of the most common dilemmas Go developers face. This guide will help you make the right decision with confidence.

Introduction

Go's simplicity is one of its greatest strengths, but that simplicity sometimes presents developers with interesting choices. One such choice arises when you need to organize and work with structured data: should you use a map or a struct?

While both serve as containers for data, they have fundamentally different characteristics that make each better suited for specific scenarios. Understanding these differences is crucial for writing efficient, maintainable Go code.

In this article, we'll explore the technical differences, performance characteristics, and practical use cases for both data structures, helping you make informed decisions in your projects.

Understanding the Basics

What are Structs?

Structs are typed collections of fields. It groups multiple related variables (fields) of different data types together under a single name to organize data efficiently. They're compile-time constructs that define a fixed schema for your data. Each field has a name, a type, and can have tags for metadata like JSON serialization.

go
type User struct {
    ID        int       `json:"id"`
    Name      string    `json:"name"`
    Email     string    `json:"email"`
    CreatedAt time.Time `json:"created_at"`
}

When you create a struct instance, the memory layout is fixed and known at compile time. This predictability is a key feature that enables excellent performance and type safety.

What are Maps?

Maps are dynamic key-value stores where all keys and values must be of the same type (or satisfy an interface). They're runtime constructs whose structure can change as your program executes.

go
user := map[string]interface{}{
    "id":        123,
    "name":      "Alice",
    "email":     "alice@example.com",
    "createdAt": time.Now(),
}

Performance Comparison

Memory Allocation

Structs allocate memory contiguously in a single block:

go
type Point struct {
    X, Y, Z float64
}

// Single allocation: 24 bytes (3 * 8 bytes)
p := Point{X: 1.0, Y: 2.0, Z: 3.0}

Maps require multiple allocations:

go
// Multiple allocations: map header, buckets, keys, values
data := map[string]float64{
    "x": 1.0,
    "y": 2.0,
    "z": 3.0,
}

Access Speed

go
func BenchmarkStructAccess(b *testing.B) {
    user := User{ID: 1, Name: "John"}
    for i := 0; i < b.N; i++ {
        _ = user.Name
    }
}

func BenchmarkMapAccess(b *testing.B) {
    user := map[string]interface{}{"name": "John"}
    for i := 0; i < b.N; i++ {
        _ = user["name"]
    }
}

Results:

text
BenchmarkStructAccess-8    1000000000    0.28 ns/op    0 B/op    0 allocs/op
BenchmarkMapAccess-8       100000000    11.5 ns/op    0 B/op    0 allocs/op
Struct access is ~40x faster than map access!

Type Safety: The Compile-Time Guardian

Structs Catch Errors Early
With structs, the compiler catches mistakes before they reach production:

go
type Product struct {
    Name  string
    Price float64
}

func UpdatePrice(p *Product, newPrice float64) {
    p.Price = newPrice
}

// Compilation errors:
p := Product{Name: "Laptop", Price: 999.99}
p.Price = "invalid" // cannot use string as float64
p.Stock = 50 // unknown field

Maps Require Runtime Checks
Maps sacrifice type safety for flexibility:

go
data := map[string]interface{}{"price": 99.99}

// Runtime type assertion required
price, ok := data["price"].(float64)
if !ok {
    return errors.New("invalid price type")
}

// This compiles but panics at runtime
price := data["price"].(int) // panic: interface conversion

When to Use Structs

Domain Models Structs excel at representing real-world entities:

go
type Order struct {
    ID          int64     `json:"id"`
    CustomerID  int64     `json:"customer_id"`
    Total       float64   `json:"total"`
    Status      string    `json:"status"`
    CreatedAt   time.Time `json:"created_at"`
}

func (o *Order) Validate() error {
    if o.Total <= 0 {
        return errors.New("order total must be positive")
    }
    return nil
}

API Contracts Structs with JSON tags provide clean serialization:

go
type CreateUserRequest struct {
    Name     string `json:"name" validate:"required"`
    Email    string `json:"email" validate:"required,email"`
    Password string `json:"password" validate:"required,min=8"`
}

Configuration Management Configuration is typically well-defined:

go
type Config struct {
    Host     string        `yaml:"host"`
    Port     int           `yaml:"port"`
    Timeout  time.Duration `yaml:"timeout"`
    Database DatabaseConfig `yaml:"database"`
}

Database Models Structs work perfectly with ORMs:

go
type User struct {
    ID        int64     `db:"id"`
    Username  string    `db:"username"`
    Email     string    `db:"email"`
    CreatedAt time.Time `db:"created_at"`
}

When You Need Methods

go
type Calculator struct {
    Precision int
}

func (c *Calculator) Add(a, b float64) float64 {
    return math.Round((a+b)*float64(c.Precision)) / float64(c.Precision)
}

When to Use Maps

Dynamic Data When the data structure is unknown at compile time:

go
func ProcessWebhook(payload map[string]interface{}) error {
    eventType, ok := payload["type"].(string)
    if !ok {
        return errors.New("missing event type")
    }

    switch eventType {
    case "user.created":
        return processUserCreated(payload)
    case "order.completed":
        return processOrderCompleted(payload)
    default:
        return fmt.Errorf("unknown event type: %s", eventType)
    }
}

Dynamic Keys When keys come from external sources:

go
func BuildQueryParams(params map[string]string) string {
    var queryParts []string
    for key, value := range params {
        queryParts = append(queryParts, fmt.Sprintf("%s=%s", key, value))
    }
    return strings.Join(queryParts, "&")
}

HTTP Headers HTTP headers are inherently dynamic:

go
func SetHeaders(headers map[string]string) {
    for key, value := range headers {
        w.Header().Set(key, value)
    }
}

Caching Maps are excellent for simple caches:

go
type Cache struct {
    store map[string]interface{}
    mu    sync.RWMutex
}

func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    value, ok := c.store[key]
    return value, ok
}

Counting or Set Operations

go
// Using map as a set
activeUsers := make(map[string]bool)
activeUsers["alice@example.com"] = true

// Counting occurrences
wordCount := make(map[string]int)
for _, word := range words {
    wordCount[word]++
}

The Hybrid Approach

You don't have to choose just one. Combine both where appropriate:

go
type User struct {
    ID         int
    Name       string
    Attributes map[string]interface{} // Dynamic attributes
}

func (u *User) GetAttribute(key string) interface{} {
    return u.Attributes[key]
}

This gives you the best of both worlds: fixed fields for core data and dynamic fields for extensibility.

Decision Framework

Use this flowchart to guide your decision:

text
Is the data structure fixed at compile time?
│
├── Yes ──> Does performance matter?
│ │
│ ├── Yes ──> Use STRUCT
│ │
│ └── No ───> Use STRUCT (still better!)
│
└── No ────> Are keys dynamic or from user input?
│
├── Yes ──> Use MAP
│
└── No ───> Consider STRUCT or MAP based on other needs

Quick Decision Rules

Use Structs When:

You know the data shape at compile time
Performance is critical
Type safety is important
You need methods or interfaces
The data represents a business entity
You want self-documenting code
You're working with JSON/XML serialization

Use Maps When:

The data structure is truly dynamic
Keys come from user input or external sources
You need to iterate over all fields generically
You're working with HTTP headers or query params
You need a set or counting structure
You're caching arbitrary data

Common Pitfalls to Avoid

Using Maps for Everything

go
// Hard to maintain and error-prone
func ProcessUser(data map[string]interface{}) {
    name, _ := data["name"].(string) // Potential panic
    age, _ := data["age"].(int)      // Might be float64 from JSON
}

Using Structs for Highly Dynamic Data

go
// Adding fields requires code changes
type DynamicData struct {
    Field1 string
    Field2 string
    // Field3 needed? Must modify struct
}

Mixing Types Without Clear Semantics

go
// Avoid this pattern
data := map[string]interface{}{
    "id": 123,
    "name": "Alice",
    "tags": []string{"admin", "user"},
    "settings": map[string]interface{}{
        "notifications": true,
    },
}

Best Practices

Default to Structs
In 80% of cases, structs are the better choice. Start with structs and only switch to maps when you have a specific reason.
Use Typed Maps When Possible

go
// Better than map[string]interface{}
type Attributes map[string]string

Validate Map Data Early

go
func validateUser(data map[string]interface{}) error {
    required := []string{"name", "email"}
    for _, field := range required {
        if _, ok := data[field]; !ok {
            return fmt.Errorf("missing required field: %s", field)
        }
    }
    return nil
}

Document Map Expectations

go
// UserData must contain:
// - "name": string (required)
// - "email": string (required)
// - "age": int (optional)
func ProcessUserData(data map[string]interface{}) error {
    // Implementation...
}

Consider Conversions It's easier to convert a struct to a map than the reverse:

go
// Convert struct to map
func ToMap(v interface{}) map[string]interface{} {
    result := make(map[string]interface{})
    data, _ := json.Marshal(v)
    json.Unmarshal(data, &result)
    return result
}

Conclusion

Choosing between maps and structs in Go comes down to understanding your data's nature and your application's requirements.

Structs are the default choice for most applications. They provide:

Compile-time type safety
Superior performance (40x faster access)
Self-documenting code
Better memory efficiency
Method support
Interface implementation

Maps shine in specific scenarios:

Dynamic data structures
Unknown or user-defined schemas
Generic iteration over fields
HTTP headers and query parameters
Caching and counting operations

Remember: You can always refactor from structs to maps if needed, but the reverse is much harder and more error-prone.

What's your experience with maps vs structs in Go? Share your thoughts in the comments below!

Enjoyed this article? Follow me for more Go insights and best practices.

Why Port 8080 and Not 80? A Beginner’s Tale in Go

Margaret Apiyo — Fri, 15 May 2026 07:40:58 +0000

****I

recently started my coding journey with Go. If you’re a beginner looking for a language that is simple yet incredibly powerful, I can’t recommend Go enough.

While building my first Go HTTP web server, I hit a point of curiosity. I learned that a server must "listen" on a specific port number, but I kept seeing 8080 in every tutorial instead of the standard 80.

I did some digging, and here is what I found.

What exactly is a Port?

Think of an IP address as the building address and a Port as the specific door (entry point). The port number decides which software gets the request. When a server "listens" on a port, it means the software is standing behind that door, waiting for someone to knock.

The "Conflict" Rule

On your local machine, only one process can bind to a specific port at a time.
If you have Apache, Nginx, or another system service already listening on Port 80, your Go application will crash on startup. The OS will essentially tell you: "That door is already taken!" By using 8080, you avoid crashing into the main web services already running on your machine.

The "Root" Problem (Privileged Ports)

There is a second reason beginners use 8080 that is even more important: Permissions.
In Unix-like operating systems (Linux and macOS), ports numbered 1 to 1023 are considered "Privileged Ports."
Port 80 requires administrative (root) privileges to run.
Port 8080 is an unprivileged port.

Think of it like this:
Door 80: Imagine this door has a "Security Clearance Required" sign. Only the "System Admin" (Root/Sudo) has the key.
Door 8080: This is an open side entrance. Any developer (standard user) can walk through it and set up shop.

As a developer, you don't want to run your Go binary with sudo every time you test a change. Using 8080 allows you to run your code as a normal user, making your development workflow much smoother and safer.

Why the number 8080?

You might wonder: “Why not 1234 or 9999?”
Technically, you could! However, 8080 became the industry standard because it literally looks like "two 80s." It’s the universal signal to other developers saying: "This is a web server, but it's for development/alternative use."

A Quick Example in Go
In case you’re wondering how this looks in code, here is how we "listen" on 8080 in Go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello! You've reached the Go server on port 8080.")
    })

    fmt.Println("Server starting on :8080...")
    // We use :8080 to avoid permission issues and port conflicts
    http.ListenAndServe(":8080", nil)
}

Summary

Port 80: The default for HTTP. Requires "Root" permissions.

Port 8080: The "Alternative" to 80. Easy to use for development without special permissions.

Understanding these small "why" questions makes the coding journey so much more rewarding. If you're just starting with Go like me, keep questioning the default`