Avoiding Boilerplate: Using Generics and Reflection for JSON Parsing in Go 1.18+

Hello, I'm Shrijith. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

JSON parsing in Go can feel repetitive. You define structs, call json.Unmarshal, and repeat for every API response or config.

Go 1.18 introduced generics, and with reflection, we can reduce boilerplatee while keeping type safety.

This post explores how generics and reflection simplify JSON parsing, with complete examples, tradeoffs, and practical tips.

1. Why JSON Parsing Needs a Rethink

Go’s static type system ensures reliability but leads to verbose JSON handling. Every JSON payload needs a struct, and dynamic or nested data makes this tedious. Go 1.18’s generics and the reflect package offer abstractions to cut down on repetitive code while keeping it maintainable.

• Motivation: Less duplication, better handling of dynamic JSON.
• What’s new: Generics for type-safe abstractions; reflection for runtime flexibility.

2. The Problem: Verbose JSON Handling in Idiomatic Go

In idiomatic Go, JSON parsing looks like this:

package main

import (
    "encoding/json"
    "fmt"
    "log"
)

type User struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

func main() {
    data := []byte(`{"id": 1, "name": "Alice"}`)
    var user User
    if err := json.Unmarshal(data, &user); err != nil {
        log.Fatal(err)
    }
    fmt.Printf("User: %+v\n", user)
    // Output: User: {ID:1 Name:Alice}
}

This works for simple cases but struggles with:

• Nested or repetitive JSON: APIs with many fields or configs with similar structures.
• Dynamic content: APIs where fields vary (e.g., GitHub’s API payloads).
• Maintenance: JSON changes require updating structs and tests.

Case study: Parsing a nested config like:

{
  "database": {"host": "localhost", "port": 5432},
  "api": {"endpoint": "https://api.example.com", "key": "xyz"}
}

You’d need structs for Database, API, and the parent Config. Any JSON change means updating multiple structs.

3. Option 1: Using Generics to Abstract Parsing

Go 1.18’s generics enable a reusable JSON parsing function. Here’s a complete example:

package main

import (
    "encoding/json"
    "fmt"
    "log"
)

func ParseJSON[T any](data []byte) (T, error) {
    var result T
    if err := json.Unmarshal(data, &result); err != nil {
        return result, fmt.Errorf("parsing JSON: %w", err)
    }
    return result, nil
}

type User struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

type Config struct {
    Database struct {
        Host string `json:"host"`
        Port int    `json:"port"`
    } `json:"database"`
}

func main() {
    // Example 1: Parsing a user
    userData := []byte(`{"id": 1, "name": "Alice"}`)
    user, err := ParseJSON[User](userData)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("User: %+v\n", user)
    // Output: User: {ID:1 Name:Alice}

    // Example 2: Parsing a config
    configData := []byte(`{"database": {"host": "localhost", "port": 5432}}`)
    config, err := ParseJSON[Config](configData)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("Config: %+v\n", config)
    // Output: Config: {Database:{Host:localhost Port:5432}}
}

Benefits

• Type safety: The compiler ensures T matches the target struct.
• Less duplication: One function handles all structs.
• Reusable: Works for any JSON-compatible type.

Tradeoffs

• No field introspection: Generics can’t dynamically inspect or modify fields.
• Static types only: You need to know the type at compile time.

Link: Go Generics Documentation

4. Option 2: Using Reflection for Dynamic JSON Processing

When JSON structures vary at runtime (e.g., optional fields or unknown schemas), reflection is useful. The reflect package allows dynamic inspection and modification of types.

Example: Dynamic Schema Mapping with Defaults

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "reflect"
)

func ParseWithDefaults(data []byte, target interface{}) error {
    if err := json.Unmarshal(data, target); err != nil {
        return fmt.Errorf("unmarshaling: %w", err)
    }

    val := reflect.ValueOf(target).Elem()
    for i := 0; i < val.NumField(); i++ {
        field := val.Field(i)
        if field.IsZero() {
            switch field.Kind() {
            case reflect.String:
                field.SetString("default")
            case reflect.Int:
                field.SetInt(0)
            }
        }
    }
    return nil
}

type Settings struct {
    Theme string `json:"theme"`
    Limit int    `json:"limit"`
}

func main() {
    settings := &Settings{}
    data := []byte(`{"theme": "dark"}`) // Limit is missing
    err := ParseWithDefaults(data, settings)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("Settings: %+v\n", settings)
    // Output: Settings: {Theme:dark Limit:0}
}

Benefits

• Runtime flexibility: Handles unknown or optional fields.
• Custom logic: Add defaults, validate fields, or transform values dynamically.
• No predefined structs: Useful for schemaless JSON.

Tradeoffs

• Performance: Reflection is slower than static unmarshaling.
• Complexity: Error handling and debugging are harder.
• Type safety: You lose compile-time guarantees.

Link: Go Reflect Package

5. Combining Generics and Reflection

Combining generics and reflection leverages generics for type-safe instantiation and reflection for runtime metadata. A practical use case is a generic HTTP client that fetches and decodes JSON into any type.

Example: Generic HTTP Client

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "log"
    "net/http"
    "reflect"
)

func ParseJSON[T any](data []byte) (T, error) {
    var result T
    if err := json.Unmarshal(data, &result); err != nil {
        return result, fmt.Errorf("parsing JSON: %w", err)
    }
    return result, nil
}

func FetchAndDecode[T any](url string) (T, error) {
    var result T
    resp, err := http.Get(url)
    if err != nil {
        return result, fmt.Errorf("fetching %s: %w", url, err)
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return result, fmt.Errorf("reading body: %w", err)
    }

    // Use reflection to check for required fields
    val := reflect.ValueOf(&result).Elem()
    for i := 0; i < val.NumField(); i++ {
        if tag := val.Type().Field(i).Tag.Get("json"); tag == "" {
            return result, fmt.Errorf("field %s missing json tag", val.Type().Field(i).Name)
        }
    }

    return ParseJSON[T](body)
}

type Repo struct {
    Name  string `json:"name"`
    Stars int    `json:"stargazers_count"`
}

func main() {
    repo, err := FetchAndDecode[Repo]("https://api.github.com/repos/golang/go")
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("Repo: %+v\n", repo)
    // Output: Repo: {Name:go Stars:127412} (Stars approximate, depends on API response)
}

Benefits

• Type-safe: Generics ensure the return type matches T.
• Dynamic validation: Reflection checks for proper JSON tags.
• Reusable: One function for any API endpoint.

Tradeoffs

• Overhead: Reflection adds runtime cost.
• Complexity: Combining both requires careful error handling.

6. Practical Considerations

Performance

Approach	Speed	Use Case
Static Structs	Fastest	Known schemas, high throughput
Generics	Comparable to static	Reusable code, static types
Reflection	Slower (10-100x)	Dynamic schemas, flexibility

Reflection overhead is noticeable in tight loops or high-throughput systems. JSON decoding is often the bottleneck, not reflection.

Debuggability

• Generics: Errors are clear (e.g., json: cannot unmarshal string into int).
• Reflection: Errors are vague (e.g., reflect: field index out of range). Log field names and types for clarity.

When to Use Static Structs

• Small, stable JSON schemas.
• Performance-critical paths.
• When simplicity trumps flexibility.

7. Alternatives and Tooling

Code Generation

Tools like easyjson generate optimized parsing code:

• Pros: Fast, no reflection.
• Cons: Extra build step, less flexible.

Dynamic Schema Validation

• gojsonschema: Validate JSON against schemas.
• Cue: Define and validate data shapes with a dedicated language.
• Pros: Runtime safety, no structs needed.
• Cons: Learning curve, runtime overhead.

Tradeoffs

Tool	Flexibility	Speed	Complexity
easyjson	Low	High	Medium
gojsonschema	High	Medium	High
Cue	High	Medium	High

8. Picking the Right Tool for JSON Parsing

Generics are ideal for reusable, type-safe parsing with known types. Reflection suits dynamic or schemaless JSON but adds complexity. Static structs are best for simple, stable schemas.

Rules of Thumb

• Use static structs for small, predictable JSON.
• Use generics for reusable utilities across known types.
• Use reflection for dynamic or runtime-driven parsing.
• Consider code generation for performance-critical paths.

Looking Forward

Go’s type system is evolving. Future versions might improve reflection APIs or add generic-friendly JSON tools. For now, generics and reflection provide a powerful toolkit for cleaner JSON handling.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 |

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

 

     

---

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

• 🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
• 🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
• 🔁 Build a…

View on GitHub