Network Programming in Go: From Local Goroutines to Talking Over the Wire

Go makes concurrency feel natural — but real magic happens when your code starts talking to the outside world. Here’s how to take your Go skills from local routines to network-ready services.

Photo by NASA on Unsplash

Last time we discussed **concurrent programming in Go, the Two Generals Problem, and [how Go’s channels make synchronization surprisingly clean](https://medium.com/stackademic/coordinating-an-attack-on-a-city-with-raft-in-golang-6521304aa7b8).**

That was all about machines handling multiple tasks inside one process.

But today we’re leaving the comfort zone.

Because the moment your program needs to talk to another machine, everything changes.

Now you’re dealing with networks, unreliable communication, timeouts, serialization, API design… and a much bigger world.

So let’s open the next chapter:

Network Programming with Go

Before we build bigger distributed systems, we need a solid foundation on how Go handles communication between programs — whether that’s HTTP, JSON, TCP sockets, or simple REST endpoints.

Go and Data on the Wire

Whenever two systems talk, they need a common language. In Go, this means:

• Serialize structs → JSON (or XML, protobuf, etc.)
• Transfer over HTTP
• Deserialize on the other side

Go’s standard library makes this almost too easy.

Here’s a simple example — let’s pretend we’re writing a tiny “user profile” service.

type Profile struct {
    Name  string `json:"name"`
    Level int    `json:"level"`
    Bio   string `json:"bio"`
}

func main() {
    incoming := `{"name": "Dustin", "level": 42, "bio": "Go enjoyer"}`

    var p Profile
    if err := json.Unmarshal([]byte(incoming), &p); err != nil {
        log.Fatal(err)
    }

    fmt.Printf("%s (Lvl %d): %s\n", p.Name, p.Level, p.Bio)

    outgoing, _ := json.Marshal(p)
    fmt.Println("Serialized again:", string(outgoing))
}

Go’s reflection makes the struct tags (json:”name”) work seamlessly.

This is the foundation of every network service — clean, predictable data transfer.

REST: The Communication Style We All Use

You know REST, but here’s the short reminder:

• Uses HTTP
• Transfers JSON or XML
• Stateless — the server forgets you as soon as the request ends
• Each resource has a clear URI
• Operations use HTTP verbs (GET, POST, PUT, DELETE)
• Errors are communicated via status codes

It’s simple, universal, and Go handles it beautifully without frameworks.

Building a Tiny REST API in Go

Below is a example — a small “task API” you can run locally:

type Task struct {
    ID   int    `json:"id"`
    Text string `json:"text"`
    Done bool   `json:"done"`
}

var tasks = []Task{
    {ID: 1, Text: "Learn Go network programming", Done: false},
}

func handleAllTasks(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(tasks)
}

func handleCreateTask(w http.ResponseWriter, r *http.Request) {
    var t Task
    if err := json.NewDecoder(r.Body).Decode(&t); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    tasks = append(tasks, t)
    json.NewEncoder(w).Encode(t)
}

func main() {
    http.HandleFunc("/tasks", handleAllTasks)
    http.HandleFunc("/task/new", handleCreateTask)

    log.Println("Listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Hit it with:

• curl
• HTTPie
• Postman
• Or simply your browser for GET requests

Every incoming HTTP request is automatically handled in its own goroutine, making Go’s HTTP server surprisingly scalable.

Comparing It to Java (Spring Boot)

Spring Boot is declarative:

@GetMapping("/")
public String index() {
    return "Greetings from Spring Boot!";
}

You write annotations, Spring creates the entire scaffolding.

Go is closer to the metal:

• You wire the handlers yourself
• You decide the structure
• You keep full control of the server

Both are valid approaches.

But Go’s simplicity often feels refreshing — especially when you don’t want an entire framework controlling your architecture.

Where This Is Going

This post is intentionally calm before the storm.

You now know:

• How Go structures data for network transfer
• How JSON and REST fit into the picture
• How to build small HTTP services from scratch
• The difference between declarative (Spring) and minimalistic (Go) server design

And this is important because…

In the next articles, we’ll move deeper into more advanced Go topics:

• Generics
• Systems Programming
• Logic Programming
• And eventually, distributed algorithms that build on top of real network communication

So stay tuned — next time we’ll dial things up again.

See you soon.

— Dustin