DEV Community: Umang Mundhra

🚀 From “Works Fine” to “Feels Instant”: Tuning a GoFr API Like Engineers, Not Magicians

Umang Mundhra — Fri, 26 Dec 2025 11:41:57 +0000

A real-world story of making a GoFr API go from “fine” to “feels instant” using observability, DB tuning & service-level reliability.

Most performance stories begin dramatically — with outages, angry PMs, dashboards on fire.

Ours began mundanely.

The API was fine. It returned order details, fetched user info, stitched both, responded in a couple hundred ms. P50 looked good. No error spikes. Monitoring wasn’t screaming.

But the UI told a different story.

Click → …loading… → click → …loading again…

Not broken.
Not slow.
Just not delightful.

So we decided to see how far we could push fine toward fast — without rewriting the architecture, adding new libraries, or making the code unpleasant to work with.

This is how GoFr made that journey almost embarrassingly smooth.

🧩 The Starting Point

A simple GoFr handler:

func GetOrderDetails(ctx *gofr.Context) (any, error) {
    orderID := ctx.Param("id")

    // DB call
    var order Order
    err := ctx.SQL.QueryRowContext(ctx,
        "SELECT id, user_id, status, total FROM orders WHERE id=?", orderID,
    ).Scan(&order.ID, &order.UserID, &order.Status, &order.Total)
    if err != nil {
        return nil, err
    }

    // HTTP call
    userService := ctx.GetHTTPService("user-service")
    resp, err := userService.Get(ctx, "/users/"+order.UserID, nil)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    var user User
    json.NewDecoder(resp.Body).Decode(&user)

    return OrderDetailsResponse{Order: order, User: user}, nil
}

Clean. Predictable. One context.
Nothing to rewrite — we just needed to understand what was eating time.

🔍 Step 1 — Let Observability Tell the Story

No custom tracing, no slogging through logs, no extra plugins.
GoFr already ships with:

✔ Tracing per request
✔ SQL + HTTP span instrumentation
✔ Structured logs linked to traces

Within minutes, patterns emerged:

⛔ occasional DB spans ballooned
🟢 HTTP calls were steady
📈 latency spikes mapped to DB wait time

Mystery solved.
No guessing → just graphs.

⚡ Step 2 — Fixing the Real Culprit (SQL)

The query looked harmless:

SELECT id, user_id, status, total FROM orders WHERE id = ?

But on a growing table, “harmless” becomes “sluggish”.

We added the correct index + tuned connection pooling:

DB_MAX_OPEN_CONNS=25
DB_MAX_IDLE_CONNS=10
DB_CONN_MAX_LIFETIME=5m

No code change.

Spans shrank immediately. P95 dipped.
The app felt faster.

Step 3: Hardening the HTTP Call — The Right Way in GoFr

The downstream user service wasn’t slow, but it was still a point of risk:

if it slowed down → our API slowed down
if it failed → we returned errors upstream

Instead of wrapping custom retry logic manually, GoFr lets us configure reliability at the service layer itself — once, globally.

We updated the service registration like this:

a.AddHTTPService("user-service", "https://users.internal",
    &service.RetryConfig{MaxRetries: 3},
    &service.CircuitBreakerConfig{
        Threshold: 5,
        Interval:  2 * time.Second,
    },
    &service.RateLimiterConfig{
        Requests: 50,
        Window:   time.Second,
        Burst:    75,
    },
    &service.HealthConfig{HealthEndpoint: "health"},
)

Now every request to user-service automatically benefits from:

✔ retry handling
✔ backoff behavior
✔ rate limiting
✔ circuit breaker protection
✔ unified tracing + logging through ctx

No wrappers, no middleware sprawl, no rewriting handlers.

The handler stayed as clean as before:

func GetOrderDetails(ctx *gofr.Context) (any, error) {
    orderID := ctx.Param("id")

    // fetch order (unchanged)
    ...

    userService := ctx.GetHTTPService("user-service")

    resp, err := userService.Get(ctx, "/users/"+order.UserID, nil)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    var user User
    json.NewDecoder(resp.Body).Decode(&user)

    return OrderDetailsResponse{Order: order, User: user}, nil
}

This step didn’t drastically reduce average response time —
but it made latency spikes vanish and failures behave predictably.

That’s the difference between being fast and being reliable.

🪶 Step 4 — Send Only What UI Needs

We removed unused fields from the response payload.

Smaller payload = faster in real networks.
Performance is rarely one giant win — it’s a hundred tiny wins.

🎯 The Most Interesting Part?

Through all improvements, our handler never got messy.

func GetOrderDetails(ctx *gofr.Context) (any, error) { ... }

One context for everything:

🟦 DB
🟦 HTTP
🟦 Logs
🟦 Tracing
🟦 Metrics

No glue code. No noise. Only logic.

That’s the real win.

💭 What We Learned
Observability first → performance second
Small DB + HTTP improvements beat fancy rewrites
A unified context keeps code elegant under load
Fast is good. Predictably fast is better.
GoFr didn’t give us magic.
It gave us clarity — and clarity made us faster.

If Your API is “Fine” Today…

Before optimizing everything:

👉 trace it
👉 index what matters
👉 configure retries
👉 fix first bottleneck
👉 keep code simple

You might be one index + one retry away from delight.

📚 Try this yourself

🚀 Quick start: https://gofr.dev/docs/quick-start
💻 Source code: https://github.com/gofr-dev/gofr

Sometimes the best upgrade isn’t changing tech —
It’s unlocking the tech you already have.

🚀 The 20-Minute Production API Challenge with GoFr

Umang Mundhra — Fri, 17 Oct 2025 17:00:16 +0000

Most developers spend 4 hours setting up what GoFr does in 20 minutes.
Let’s prove it.

⏱️ The Setup Fatigue Every Go Developer Knows

ou’ve been there.  Your product manager says, “We just need a simple API that stores orders in a database and publishes events.”
Simple, right?

Then it begins:

⏱️ Hour 1: Database setup, pooling, and error handling
⏱️ Hour 2: Logging, context propagation
⏱️ Hour 3: Metrics and tracing configuration
⏱️ Hour 4: Health checks and graceful shutdowns

Four hours later… you finally write your first line of actual business logic.

GoFr changes that.   It ships with production-grade defaults — observability, migrations, PubSub, metrics — all wired automatically.

Your job? Just write code that matters.

🧩 Minute 0–5: Your First Endpoint

package main

import "gofr.dev/pkg/gofr"

func main() {
 app := gofr.New()

 app.GET("/ping", func(c *gofr.Context) (any, error) {
  return map[string]string{"message": "pong"}, nil
 })

 app.Run()
}

✅ Health checks 
✅ Metrics & tracing 
✅ Structured logs 
✅ Graceful shutdown

No config. No boilerplate. Just business logic.

🔌 Minute 5–10: Add Database & PubSub

package main

import "gofr.dev/pkg/gofr"

func main() {
    app := gofr.New()

    app.GET("/ping", func(c *gofr.Context) (any, error) {
       return map[string]string{"message": "pong"}, nil
    })

    app.Run()
}

func PublishOrder(c *gofr.Context) (any, error) {
    var order struct {
       ID     string `json:"id"`
       Status string `json:"status"`
    }

    if err := c.Bind(&order); err != nil {
       return nil, err
    }

    msg, _ := json.Marshal(order)
    return "Published", c.GetPublisher().Publish(c, "orders", msg)
}

In a few lines, you:

Parse JSON input
Serialize and publish events
Get automatic tracing, retries, and logs

Everything observable — out of the box.

🧱 Minute 10–15: Migrations as Code

package migrations

import "gofr.dev/pkg/gofr/migration"

func createUsersTable() migration.Migrate {
 return migration.Migrate{
  UP: func(d migration.Datasource) error {
   _, err := d.SQL.Exec(`CREATE TABLE IF NOT EXISTS users (
                id INT PRIMARY KEY AUTO_INCREMENT,
                name VARCHAR(50) NOT NULL
            )`)
   return err
  },
 }
}

Wire it up in main.go:

a.Migrate(migrations.All())

Run your app — GoFr automatically applies and tracks migrations.  No separate tools, no manual SQL scripts.

⚙️ Minute 15–20: CRUD in One Line

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

func (u *User) RestPath() string { return "users" }

app.AddRESTHandlers(&User{})

Boom. 

Instant REST endpoints:

POST /users
GET /users
GET /users/{id}
PUT /users/{id}
DELETE /users/{id}

All with SQL generation, validation, logging, and metrics — no extra setup.

📊 What You Built in 20 Minutes



| Capability          | Traditional Setup Time | With GoFr     |
|---------------------|------------------------|---------------|
| Database & pooling  | 45 min                 | Built-in      |
| Logging & metrics   | 60 min                 | Automatic     |
| Health checks       | 15 min                 | Automatic     |
| Tracing             | 45 min                 | Automatic     |
| Migrations          | 30 min                 | 5 min         |
| CRUD endpoints      | 60 min                 | 1 line        |
| PubSub              | 30 min                 | 5 min         |
| 
    Total**           | 4–5 hr                 | 20 min ✅     |

🔍 Observability You Didn’t Write

Structured logs:

INFO [21:30:35] Loaded config from file: ./configs/.env
DEBU [21:30:35] Container is being created
DEBU [21:30:35] connecting to redis at 'localhost:2002' on database 0
DEBU [21:30:35] hello                            REDIS      3369µs hello 3
DEBU [21:30:35] pipeline                         REDIS       399µs client setinfo LIB-NAME go-redis(,go1.25.0): ERR unknown subcommand 'setinfo'. Try CLIENT HELP.
DEBU [21:30:35] ping                             REDIS      8551µs ping
INFO [21:30:35] connected to redis at localhost:2002 on database 0
DEBU [21:30:35] generating database connection string for 'mysql'
DEBU [21:30:35] registering sql dialect 'mysql' for traces
DEBU [21:30:35] connecting to 'root' user to 'test' database at 'localhost:2001'
INFO [21:30:35] connected to 'root' user to 'test' database at 'localhost:2001'
INFO [21:30:35] Exporting traces to GoFr at https://tracer.gofr.dev
INFO [21:30:35] registered static files at endpoint /static/ from directory /Users/zopdev/Projects/GoFr.dev/gofr/examples/http-server/static
INFO [21:30:35] GoFr records the number of active servers. Set GOFR_TELEMETRY=false in configs to disable it.
INFO [21:30:35] Starting server on port: 9000
INFO [21:30:35] Starting metrics server on port: 2121
INFO [21:30:40] 82266bb78cdd997f43ce242b665c3b49 Name came empty
INFO [21:30:40] 82266bb78cdd997f43ce242b665c3b49 200         271µs GET /hello 
DEBU [21:30:44] QueryRowContext                  SQL           4µs select 2+2
INFO [21:30:44] dfcdd5085b9542dc5ef17bf52bbae508 200        4858µs GET /mysql

Metrics (Prometheus):

app_http_response
app_sql_stats
app_pubsub_publish_total_count

Tracing:  Every request is automatically traced through HTTP → SQL → PubSub.  No extra code, no instrumentation needed.

💡 Why This Matters

When setup takes hours, iteration slows.  GoFr removes that friction.

✅ Faster onboarding 
✅ Consistent architecture 
✅ Built-in reliability 
✅ Zero boilerplate

Production-ready doesn’t have to mean setup-heavy.

🧭 Your Turn:

Step 1:

go get gofr.dev

Step 2:  Set a timer for 20 minutes.
Step 3:  Build your first fully observable, database-backed API.
Step 4:  Share your result with the community.

👉 Quick Start Guide → 
👉 Example Repos →

The best code is the code you don’t have to write.

GoFr lets you skip the setup — and start shipping.

💬 If You Enjoyed This

Leave a comment with how fast you built yours. 

Tag it with #GoFrChallenge — and let’s see how many developers can beat the 20-minute mark.

Open Source in 2025: A Door You Can Walk Through

Umang Mundhra — Mon, 08 Sep 2025 06:22:51 +0000

When people hear “open source contribution,” many imagine a massive, complex codebase guarded by experts. It feels like a giant rock — immovable, intimidating, and impossible to climb.

But here’s the truth: open source isn’t a rock. It’s a door. And once you knock, you’ll realize it’s far more open than you think.

The GSOC 2025 Reality Check

This year’s Google Summer of Code (GSoC 2025) paints a fascinating picture:

98,698 developers registered from 172 countries.
Only 1,280 contributors were selected.
And here’s the kicker: 43% of accepted contributors had never contributed to open source before.

That means nearly half the selected contributors started from scratch — no previous experience, no big projects behind them. Just curiosity and persistence.

So if they can do it, what’s stopping you?

A Story from GoFr Summer of Code

At GoFr — our open-source Golang framework — we took a leap of faith and organized our first ever GoFr Summer of Code (GoFr SoC) this summer. The response truly amazed us!

The numbers tell an incredible story:

✨ 2,454+ engagements and 65,310+ impressions from the community
📝 109 proposals submitted by passionate developers
✅ 38 contributors selected to work on real problem statements with GoFr
🎉 8 contributors successfully completed their projects, merging their PRs into the GoFr codebase
Over two months, contributors worked on meaningful features like OnStartHook implementations and database integrations including CouchBase and OracleDB. These weren’t trivial — they were real enhancements that strengthened GoFr’s ecosystem.

👉 Example: PR #2052 — a student contributor successfully integrated OracleDB support after learning the framework’s database adapter patterns in just weeks.

What made the difference wasn’t fancy degrees or years of experience. It was their willingness to learn — and their smart use of modern development tools.

How AI Has Changed the Open Source Game

Contributing to open source used to feel like wandering a maze blindfolded.

Now, tools like GitHub Copilot, Cursor, and Windsurf can:

Summarize project structure in plain English
Trace how functions flow across files
Suggest relevant docs/tests for an issue
Help you quickly onboard into unfamiliar codebases
This doesn’t mean AI replaces you. The best contributors use it as an accelerator for learning, not a shortcut for thinking.

Our GoFr Summer of Code contributors leveraged these tools to understand complex database integration patterns and framework architectures. The AI didn’t write their code — it helped them navigate and comprehend existing patterns so they could contribute authentically.

Your Pathway into Open Source in 2025

Here’s a simple, practical roadmap to start contributing:

1. Pick Your Tools
Choose an AI assistant that fits your workflow — Copilot, Cursor, Windsurf, or even ChatGPT. Use it to clarify confusing code, not to write blind PRs.

2. Find Your Community (Not Just a Repo)
Look for projects where maintainers respond, issues are tagged clearly, and contributors are welcomed.

For Go enthusiasts: GoFr has beginner-friendly issues
For frontend devs: React, Vue, or Astro communities are great starting points
For infra lovers: Kubernetes and CNCF projects always need contributors

3. Start Small, Build Trust
Every GoFr Summer of Code contributor began with small fixes — typos, docs, missing tests. These “low-hanging fruits” helped them build confidence and trust.

Think of it as leveling up:

Week 1–2: Fix docs, add missing tests
Week 3–4: Pick good-first-issues
Month 2+: Implement small features
Month 3+: Propose architectural improvements

4. Use AI for Clarity, Not Shortcuts

Let AI explain a file, or generate a draft test. But never submit something you don’t fully understand. Remember: a PR is valuable because you understood the code and improved it.

Why This Matters

Open source is more than code. It’s about community, mentorship, and real-world impact.

For beginners: it’s the fastest way to learn beyond classrooms
For students: it builds credibility far greater than college projects
For professionals: it’s a way to give back and sharpen your skills

And in 2025, with AI lowering the barrier, the opportunities are endless.

An Open Invitation

You don’t need to contribute to GoFr — though we’d love to welcome you to our community. The point is to pick a project you care about and take the first step.

Because those eight students who successfully contributed to GoFr weren’t special. They just started.

The Door Is Open

Open source contribution in 2025 isn’t a mountain to climb — it’s a door waiting for you to walk through.

AI has made the map clearer. Communities are more open than ever. Opportunities are everywhere.

So the question isn’t whether you’re ready.
The real question is: which door will you walk through?

✨ The future of technology is collaborative. And it’s waiting for you.

GoFr.dev Website: https://gofr.dev/
GoFr.dev Github: https://github.com/gofr-dev/gofr

Effortless Event-Driven Go APIs with GoFr: The Simplest Pub/Sub You’ll Ever Code

Umang Mundhra — Wed, 14 May 2025 08:42:40 +0000

Modern software isn’t just fast — it’s instant. Modern applications demand responsiveness, scalability, and the ability to react in real-time to various triggers. From food delivery apps notifying you about your order to stock trading platforms processing millions of transactions, event-driven architectures (EDA) power real-time magic.

And when it comes to crafting robust backend systems, Go (Golang) has emerged as a frontrunner. Its concurrency model, performance, and strong ecosystem make it an ideal choice for building high-throughput and reliable applications.

In this article, you’ll learn why event-driven patterns matter, the common pitfalls developers face, and — most importantly — how GoFr makes publishing, subscribing, and monitoring messages from a chore into a 10-minute coffee break.

The Pub/Sub Puzzle:

Despite Go’s strengths, implementing a truly efficient and developer-friendly event-driven backend isn’t always a walk in the park. Developers often grapple with several challenges:

Integration Headaches: Connecting and configuring various pub/sub message brokers (like Kafka, RabbitMQ, Google Pub/Sub) within your API can introduce significant complexity. Each often comes with its own set of configurations, client libraries, and nuances.
Producer and Consumer Choreography: Setting up producers to reliably publish messages and consumers to subscribe and process them efficiently requires careful consideration of error handling, message formats, and concurrency.
Message Handling Complexity: Ensuring messages are properly serialized, deserialized, validated, and processed without data loss or inconsistencies can add substantial overhead to development.
Observability Blind Spots: Tracing a message across services without correlation IDs is like finding a needle in a haystack.
These complexities can lead to increased development time, potential for errors, and a steeper learning curve for teams adopting event-driven patterns in Go.

Developers waste time reinventing wheels. GoFr replaces wheels with rockets.

GoFr to the Rescue: Effortless Pub/Sub Unleashed:

Why do we keep saying “easiest”? Because GoFr abstracts away much of the underlying complexity, allowing you to focus on your application’s logic rather than wrestling with intricate pub/sub configurations. Let’s see it in action:

GoFr abstracts all of that. With just three method calls, you can publish, subscribe, and let GoFr handle the rest:

1. Publishing in 3 Lines of Code

Want to publish an order status? Here’s all the code you’ll write:

func order(ctx *gofr.Context) (any, error) {  
    var data struct { OrderId, Status string }  
    ctx.Bind(&data)  // Auto-parses incoming JSON  

    ctx.GetPublisher().Publish(ctx, "order-logs", data) // Boom. Published.  
    return "Done", nil  
}

No manual serialization. No connection pooling. Just Publish().

2. Subscribing? Even Easier

app.Subscribe("order-status", func(c *gofr.Context) error {  
    var order struct { OrderId, Status string }  
    c.Bind(&order)  // Incoming message auto-decoded  

    c.Logger.Info("Order received: ", order)  
    return nil  
})

GoFr auto-decodes messages, logs errors, and even handles retries for failed messages (return an error to replay a message)

3. Connect Any Broker in 30 Seconds

GoFr comes ready for Kafka, Google Pub/Sub, and MQTT out of the box — just set environment variables:

# For Kafka
PUBSUB_BACKEND=KAFKA
PUBSUB_BROKER=localhost:9092
CONSUMER_ID=order-consumer

# For Google Pub/Sub
PUBSUB_BACKEND=GOOGLE
GOOGLE_PROJECT_ID=project-order
GOOGLE_SUBSCRIPTION_NAME=order-consumer

# For MQTT
PUBSUB_BACKEND=MQTT
MQTT_HOST=localhost
MQTT_PORT=1883
MQTT_CLIENT_ID_SUFFIX=test

🔥 Zero Code Changes: Switch from Kafka to Google Pub/Sub by updating .env — no Go code changes needed.

Extending to Azure Event Hub, NATS, and More

What about other powerful pub/sub technologies like Azure Event Hub or NATS? GoFr’s extensibility shines here. You can easily integrate them using dedicated GoFr client packages:

import (
   "time"
   "gofr.dev/pkg/gofr"
   "gofr.dev/pkg/pubsub/nats"
)

func main() {
    app := gofr.New()

    app.AddPubSub(nats.New(nats.Config{
        Server: "nats://localhost:4222",
        Stream: nats.StreamConfig{
            Stream:   "mystream",
            Subjects: []string{"orders.*", "shipments.*"},
        },
        MaxWait:     5 * time.Second,
        MaxPullWait: 500 * time.Millisecond,
        Consumer:    "my-consumer",
        CredsFile:   "/path/to/creds.json",
    }))

    // …publish/sub as usual…
    app.Run()
}

Same for Azure Event Hub — just drop in the eventhub client and configure.

4. Observability Built-In, Not Bolted-On

Every message in GoFr carries a correlation ID for seamless tracing:

DEBU [19:51:38] 82984da1ceb51b75d3e6295d525a2218 KAFKA     48610µs PUB  products {"productId":"1221","price":"Rs. 2000"}

INFO [19:51:38] 82984da1ceb51b75d3e6295d525a2218 201       56115µs POST /publish-product

This automatic correlation, coupled with GoFr’s default metrics setup, empowers developers to gain deep insights into their application’s performance and easily pinpoint any issues in their event flow.

Real-World Benefits: Why Teams Choose GoFr for Pub/Sub

Implementing pub/sub with GoFr provides several tangible benefits:

Accelerated development: What might take days to set up properly can be accomplished in hours with GoFr.
Reduced cognitive load: Developers can focus on business logic rather than messaging infrastructure.
Consistent patterns: The unified interface promotes consistent code across services.
Future-proofing: The ability to switch messaging backends without code changes protects against vendor lock-in.
Production readiness: Built-in observability features mean systems are ready for production monitoring from day one

Getting Started with GoFr Pub/Sub

Ready to simplify your event-driven architecture? Here’s how to get started:

Install GoFr: go get gofr.dev
Set up your preferred message broker (Kafka, Google PubSub, MQTT, etc.)
Configure your application with the appropriate environment variables.
Follow the publishing and subscribing patterns shown above

For comprehensive documentation, visit GoFr’s official pub/sub guide.

Conclusion: The Future of Go Pub/Sub Is Simple

GoFr isn’t just a framework — it’s a productivity hack. By abstracting pub/sub complexities, it lets you focus on what matters: writing business logic that delights users.

With just a handful of methods, you gain powerful broker-agnostic pub/sub, structured logs, metrics, and tracing — all while writing idiomatic Go. Give GoFr a spin today, share your feedback on GitHub, and help us continue making pub/sub in Go the easiest it’s ever been!

🚀 Ready to Stop Wrestling Pub/Sub?

Star ⭐ GoFr on GitHub (It helps the project grow!)
Join fellow Developers in our Discord community
**Build your first event-driven API in 10 minutes **with our Quickstart Guide

Because in the world of real-time systems, the fastest developer wins. 🚀

Is Switching from Gin to GoFr in 2025 Worth It?

Umang Mundhra — Tue, 08 Apr 2025 06:14:17 +0000

In 2025, a single microservice might rely on 12+ dependencies - from tracing tools to circuit breakers - just to meet production standards. Frameworks that force developers to write glue code are no longer assets; they're liabilities.

Gin served us well. For years, it was the go-to framework for lightweight APIs. But as microservices evolved, so did their demands: distributed tracing, multi-protocol communication, and polyglot data layers are now non-negotiable.

GoFr isn't just another framework - it's a productivity multiplier. Built for the cloud-native era, it replaces weeks of boilerplate with conventions that let developers focus on what matters: business logic, not glue code. Let's explore why 2025 is the year to make the switch.

Introduction: The Evolution of Microservices and the Need for Modern Tooling

"In 2014, when Gin was born, microservices were a budding concept. Fast forward to 2025: distributed systems dominate, and developers need frameworks that do more than just route requests."

The tech landscape has shifted dramatically. Cloud-native apps now demand observability, resilience, and polyglot data storage. Teams juggle Kubernetes clusters, event-driven architectures, and global user bases. While Gin served as a trusty sidekick for REST APIs, modern microservices require frameworks built for scale, complexity, and developer agility.

Trends Driving Change:

Observability: Debugging distributed systems without built-in tracing is like navigating a maze blindfolded. Observability isn't optional - it's the oxygen for distributed systems.
Resilience: Resilience patterns (retries, timeouts, circuit breakers) are survival tools, not academic concepts.
Database Diversity: Teams mix SQL, NoSQL, and real-time brokers (Kafka, NATS) to meet dynamic needs.

So, the question arises: The question isn't "Does Gin work?" - it's "Can your team afford to maintain a framework stuck in 2014?" Can older frameworks like Gin keep up, or is it time to embrace modern alternatives like GoFr?

Gin's Legacy: A Worthy Warrior of Its Time

Let's give credit where it's due. Gin revolutionized Go web development in the 2010s. Its minimalist design and blazing performance made it the gold standard for APIs like this:

// Simple REST API in Gin  
r := gin.Default()  

r.GET("/status", func(c *gin.Context) {  
    c.JSON(200, gin.H{"status": "ok"})  
})

For monoliths or small services, Gin remains a solid choice. But microservices in 2025 aren't just APIs - they're distributed systems. When your service needs to:

Trace a request across 5+ services,
Retry failed gRPC calls to a flaky inventory database,
Authenticate users via OAuth while streaming Kafka events,

…Gin's simplicity becomes a bottleneck. You're not just routing requests anymore - you're orchestrating ecosystems.

GoFr: The Opinionated Framework for Modern Microservices

While Gin has earned its stripes over the years as a lightweight, high‑performance router, GoFr takes microservice development to the next level. Born out of the need for robust, cloud‑native solutions, GoFr is an opinionated framework designed specifically for the modern distributed systems era. It streamlines development by integrating essential features like built‑in observability, resilient inter‑service communication, extensive middleware support, and multi‑database connectivity - all under one roof.

With features like auto‑injected trace IDs, unified error handling, and built‑in support for various data stores and messaging protocols, GoFr is more than just a framework - it's a full‑stack solution that empowers your team to build, deploy, and scale microservices with confidence.

The Result? Teams ship features 2x faster, debug outages in minutes (not hours), and onboard new hires in days.

Features that make GoFr stand out:

Built-In Observability: No more stitching together Prometheus, Jaeger, and Zap. GoFr auto-injects trace IDs, logs structured data, and exposes metrics out of the box. Out‑of‑the‑box logging, tracing, and metrics collection mean you won't have to juggle multiple third‑party tools. In today's distributed systems, having native observability is essential for rapid troubleshooting and maintaining service reliability.
Robust Middleware and Authentication Support: Security isn't an afterthought with GoFr. GoFr comes with built‑in support for a variety of authentication mechanisms - including Basic Auth, API-key, and OAuth - plus a flexible middleware system. This integrated approach ensures that security and request handling are consistent across your microservices, reducing both development overhead and potential integration issues.
Multi‑Database Support & Data Migrations: Modern applications often interact with multiple data sources. From SQL and MongoDB to Cassandra and Dgraph, GoFr's extensive database support means you can choose the right data store for your application's needs without worrying about compatibility. GoFr also have built‑in data migration tools to simplify schema updates, ensuring that your services can evolve without painful downtime.
Unified Communication Channels: Inter‑service communication is at the heart of microservices. GoFr's seamless inter-service HTTP support combined with features like integrated circuit breakers and failure retry mechanisms - provide a resilient, unified approach to managing network calls.
WebSockets & Pub-Sub Communication Made Easy: GoFr simplifies event-driven architectures by supporting brokers like Kafka, EventHub, Google Pub/Sub, NATS, and MQTT. GoFr also supports websocket communication similarly. Its unified handler signature makes integrating these technologies straightforward.
Active Community & Evolving Standards: While Gin continues to enjoy popularity, GoFr is rapidly gaining momentum with active development, comprehensive documentation, and growing community support. This dynamic ecosystem means you benefit from regular
updates, innovative features, and a network of developers committed to improving microservice development practices. GoFr's active community ships critical patches 2x faster than legacy frameworks.

Other important features like panic recovery and crash handling, graceful shutdown, health-checks , environment based configs etc. make it more featuristic. By integrating many commonly required features into a single framework, GoFr reduces the risk of inconsistencies and lowers the overall maintenance burden. With fewer external dependencies to manage, your deployment processes become simpler, and your codebase remains cleaner over time.

"Spend less time wiring libraries, more time shipping features.".

Why 2025 Demands a Modern Framework Like GoFr

1. Consolidation Over Fragmentation:

Slash Tech Debt: Modern teams are drowning in fragmented tools. A typical Gin microservice requires: a logging library (Zap/Logrus), a tracing tool (OpenTelemetry), a circuit breaker (Hystrix/go-breaker), separate clients for databases (GORM, mongo-go-driver) and brokers (Sarama, NATS).

GoFr's Advantage: Replace 5+ dependencies with a single framework. Less dependency management = fewer version conflicts, faster audits, and unified documentation.

2. Async APIs Are Now Table Stakes:

RESTful endpoints alone can't handle real-time dashboards, WebSocket chats, or event-driven workflows. Gin's HTTP-only model forces developers to:

Bolt on third-party libraries for WebSockets
Write custom logic for Kafka/Redis pub-sub
Maintain separate handlers for async vs. sync

GoFr's Edge: Natively unify HTTP, gRPC, and event-driven logic in one handler. For example:

// Handle HTTP requests AND Kafka events with the same function  
app.GET("/order", handleOrder)  

app.Subscribe("order-updates", handleOrder)

3. Onboarding Speed Wins Markets:

With engineering talent at a premium, teams can't afford weeks of setup. Gin's minimalist design means:

New hires spend days wiring logging, auth, and metrics.
Every project reinvents the wheel for basic features.

GoFr's Solution: Conventions > Configuration.

The Verdict: Gin's Limits vs. GoFr's Horizon

In a rapidly evolving microservice landscape, productivity, consistency, and resilience are paramount. GoFr addresses these needs by offering an opinionated, modern framework that comes packed with integrated tools for observability, security, and inter‑service communication. With comprehensive database support, cloud‑native design, and an active community, GoFr positions itself as a future‑proof alternative to Gin for 2025 and beyond.

Why Switch?

Eliminate Boilerplate: GoFr's built-in tools replace weeks of wiring third-party libraries.
Embrace Modern Patterns: Async communication and polyglot persistence are first-class citizens.
Scale Teams, Not Complexity: Conventions reduce cognitive load for new hires.

"Gin is a framework. GoFr is an ecosystem."

Call to Action

Try GoFr: GitHub Repository
Join Developers Community: Discord.
Do checkout GoFr and it's Github Repo and support it by giving it a ⭐.

Final Word:
"Frameworks should solve today's problems, not yesterday's. In 2025, GoFr isn't just an alternative - it's the logical evolution for teams building cloud-native systems."

GoFr’s Plug-and-Play Model: Simplifying Database Interactions in Go

Umang Mundhra — Thu, 12 Dec 2024 05:22:31 +0000

In the ever-evolving landscape of software development, adaptability and modularity are essential for building scalable and maintainable applications. Databases play a critical role in modern software, and managing diverse databases efficiently is often a significant challenge. Many frameworks tightly couple database support, leading to issues with flexibility, maintenance, and performance.

GoFr is an open-source micro-service framework written in Go. It is a lightweight and extensible framework for Go that offers a unique solution to this problem with its plug-and-play database model.

This article delves into how GoFr supports multiple databases seamlessly, enabling developers to integrate their database of choice without altering the core framework. Whether you're working with MongoDB, MySQL, Clickhouse, or any other database, GoFr's approach ensures that you can effortlessly switch, extend, or maintain your database integration without adding unnecessary complexity. Let's explore how this model works and why it's a game-changer for Go developers

Challenges with Tightly Coupled Databases

In frameworks where database integrations are tightly coupled, several challenges can arise, making them less flexible and harder to maintain. Below are the key issues developers often face with such an approach:

Increased Build Size: One of the primary issues is the build size. To keep a framework lightweight, it's essential to include only the necessary dependencies in the go.mod file. When a framework tightly couples support for multiple databases, it often includes all relevant dependencies in the go.mod file. This bloats the build size, even if only one or two databases are used in an application. The additional dependencies not only increase the binary size but also make dependency management more complex.
Reduced Modularity and Flexibility: Tightly coupled databases reduce flexibility. If a developer wants to switch to a different database or use a custom implementation of a particular database, they must go through the tedious process of refactoring the entire codebase to accommodate the new database. This reduces the framework's adaptability and makes it less appealing for developers who need to work with multiple databases.
Frequent Framework Updates: Any changes to the database logic require a new release of the entire framework, even if there are no significant changes in the core code. This creates delays and forces users to update their framework version even if the changes are irrelevant to their application making the framework less agile.
Lack of Developer Control: Tightly coupled integrations limit the developers' control over the configuration and customization of their database connections. Developers are forced to adapt their applications to the framework's design rather than having the freedom to implement solutions tailored to their specific needs.

Lastly, tightly coupled databases hinder the separation of concerns. The core framework logic gets intertwined with database-specific code, making it harder to debug, maintain, and extend.

GoFr's Plug and Play Approach

To overcome the challenges of tightly coupled databases, GoFr introduces a plug-and-play model that provides seamless integration with multiple databases. This approach leverages Go's powerful interface abstraction to decouple database logic from the core framework, ensuring flexibility, maintainability, and scalability.

**Using Go's Interfaces: **At the heart of this model are Go's interfaces. By defining an interface with the necessary methods that a database client should implement, GoFr provides a blueprint for integrating any database. This abstraction allows developers to implement their own database logic while adhering to a consistent structure.

Connector Functions: To facilitate the integration, GoFr provides connector functions that allow users to initialize their database client and inject it into the application. These functions handle the setup and configuration of the database client, ensuring that it conforms to the interface requirements.

Example

For example, the interface for MongoDB might look like this:

// MongoProvider is an interface that extends Mongo with additional methods for logging, metrics, and connection management.
// Which is used for initializing datasource.
type MongoProvider interface {
 Mongo

 provider
}

// Mongo is an interface representing a MongoDB database client with common CRUD operations.
type Mongo interface {
 // Find executes a query to find documents in a collection based on a filter and stores the results
 // into the provided results interface.
 Find(ctx context.Context, collection string, filter any, results any) error

 // FindOne executes a query to find a single document in a collection based on a filter and stores the result
 // into the provided result interface.
 FindOne(ctx context.Context, collection string, filter any, result any) error

 // InsertOne inserts a single document into a collection.
 // It returns the identifier of the inserted document and an error, if any.
 InsertOne(ctx context.Context, collection string, document any) (any, error)

 // InsertMany inserts multiple documents into a collection.
 // It returns the identifiers of the inserted documents and an error, if any.
 InsertMany(ctx context.Context, collection string, documents []any) ([]any, error)

 // DeleteOne deletes a single document from a collection based on a filter.
 // It returns the number of documents deleted and an error, if any.
 DeleteOne(ctx context.Context, collection string, filter any) (int64, error)

 // DeleteMany deletes multiple documents from a collection based on a filter.
 // It returns the number of documents deleted and an error, if any.
 DeleteMany(ctx context.Context, collection string, filter any) (int64, error)

 // UpdateByID updates a document in a collection by its ID.
 // It returns the number of documents updated and an error if any.
 UpdateByID(ctx context.Context, collection string, id any, update any) (int64, error)

 // UpdateOne updates a single document in a collection based on a filter.
 // It returns an error if any.
 UpdateOne(ctx context.Context, collection string, filter any, update any) error

 // UpdateMany updates multiple documents in a collection based on a filter.
 // It returns the number of documents updated and an error if any.
 UpdateMany(ctx context.Context, collection string, filter any, update any) (int64, error)

 // CountDocuments counts the number of documents in a collection based on a filter.
 // It returns the count and an error if any.
 CountDocuments(ctx context.Context, collection string, filter any) (int64, error)

 // Drop an entire collection from the database.
 // It returns an error if any.
 Drop(ctx context.Context, collection string) error

 // CreateCollection creates a new collection with specified name and default options.
 CreateCollection(ctx context.Context, name string) error

 // StartSession starts a session and provide methods to run commands in a transaction.
 StartSession() (any, error)

 HealthChecker
}

type provider interface {
 // UseLogger sets the logger for the Cassandra client.
 UseLogger(logger any)

 // UseMetrics sets the metrics for the Cassandra client.
 UseMetrics(metrics any)

 // UseTracer sets the tracer for the Cassandra client.
 UseTracer(tracer any)

 // Connect establishes a connection to Cassandra and registers metrics using the provided configuration when the client was Created.
 Connect()
}

Here, the MongoProvider interface embeds the Mongo and provider interfaces. While the Mongo interface contains all the necessary methods that need to be implemented by the client for database operations, the provider interface contains methods needed by the framework to successfully connect to the database and use logging, metrics, and traces for observability.

This is the connector function for Mongo that accepts the implementation of MongoProvider interfaces defined by GoFr. This function configures the MongoDB client with logging, metrics, and tracing capabilities, and establishes the connection:

// AddMongo sets the MongoDB datasource in the app's container.
func (a *App) AddMongo(db container.MongoProvider) {
    db.UseLogger(a.Logger())
    db.UseMetrics(a.Metrics())
    db.UseTracer(otel.GetTracerProvider().Tracer("gofr-mongo"))
    db.Connect()
    a.container.Mongo = db
}

And this is how the user will finally use it in their application:

func main() {
    app := gofr.New()
    db := mongo.New(mongo.Config{URI: "mongodb://localhost:27017", Database: "test", ConnectionTimeout: 4*time.Second})
    app.AddMongo(db)

    app.POST("/mongo", Insert)
    app.GET("/mongo", Get)
    app.Run()
}

Advantages of GoFr's plug & play model:

Reduced Build Size: By avoiding tightly coupling databases with the core framework, GoFr keeps the framework lightweight. Only the necessary dependencies are included in the go.mod file, resulting in smaller build sizes and improved performance.
Simplified Maintenance: Maintaining database integrations becomes straightforward with GoFr's plug-and-play model. Since database logic is decoupled from the core framework, updates or changes to database connectors can be made independently, without requiring a new release of the entire framework. This reduces the maintenance burden and accelerates release cycles.
Flexibility and Modularity: The plug-and-play model in GoFr allows developers to easily integrate, switch, or extend their database of choice without altering the core framework. This flexibility ensures that developers are not locked into a single database solution and can adapt to evolving requirements with minimal effort.
Improved Observability: GoFr's connector functions are designed to incorporate logging, metrics, and tracing capabilities for each database integration. This built-in observability ensures that developers have the necessary tools to monitor and troubleshoot their database interactions effectively, leading to more robust and reliable applications.
Customization and Extensibility: Developers can easily implement their own database logic by adhering to the defined interfaces in GoFr. This customization allows for tailored database solutions that meet specific project requirements. Additionally, the ability to extend the framework with new databases enhances its versatility and adaptability.

Conclusion

GoFr's innovative plug-and-play model for database integration offers a powerful solution to the challenges posed by tightly coupled databases. By leveraging Go's interface abstraction, GoFr ensures flexibility, maintainability, and scalability, making it easier for developers to work with multiple databases without altering the core framework. This approach not only keeps the framework lightweight and modular but also simplifies maintenance and enhances overall application performance.

We invite you to try GoFr in your next project. Experience how its plug-and-play database model can simplify your development process. For more detailed information and examples, check out the following resources:

Try out GoFr, and if you find it helpful, don't forget to give it a ⭐ on GitHub. Your feedback and contributions are invaluable to the continued improvement of this framework.

The Ultimate Golang Framework for Microservices: GoFr

Umang Mundhra — Wed, 10 Jul 2024 07:18:26 +0000

Go is a multiparadigm, statically typed, and compiled programming language designed by Google. Many developers have embraced Go because of its garbage collection, memory safety, and structural typing system. Go web frameworks were created to ease Go web development processes without worrying about setups and focusing more on the functionalities of a project. While building small applications, frameworks may not be necessary, but for production-level software, they are crucial. Frameworks provide additional functionalities and services that can be used by other developers who want to add similar functionalities to their software rather than writing the full-fledged software by themselves.

Choosing the right framework for your needs can enable faster development cycles and easier maintenance down the road. In this article we will talk about GoFr, an opinionated Golang framework for accelerated microservice development. And we will discover why it is your ultimate choice when building microservices in Go!

GoFr & It's rich set of features:

What really makes a framework good or bad is the ease of development it provides for its user along with the range of features it offers so the user can purely focus on business logic implementation. GoFr has been built to help developers write fast, scalable and efficient API's. The framework offers a rich set of features that help developers in writing production grade microservices with ease. Let's explore some of these features:

1. Efficient Configuration Management

Environment variables are the best way to set configuration values for your software application as they can be defined at system-level, independently of the software. This is one of the principles of the Twelve-Factor App methodology and enables applications to be built with portability.

GoFr has some predefined environment variables for various purposes like changing log levels, connecting to databases, setting application name and version, setting http ports etc. The user just needs to set these in an .env file inside the configs directory of the application and GoFr automatically reads the values from that.

Here is the full list of environment variables supported by GoFr

2. Seamless Database Interactions

Managing database connections and interactions can become hectic, especially when working with multiple databases. GoFr handles database connections seamlessly using configuration variables. Not only does it manage the connections, but it also provides direct access to database objects using the GoFr context within handlers. This approach simplifies working with multiple databases. GoFr currently supports all SQL Dialects, Redis, MongoDB, Cassandra and ClickHouse databases.

Example of using MySQL and Redis DB inside the handler.



func DBHandler(c *gofr.Context) (interface{}, error) {

 var value int

// querying a SQL db

err := c.SQL.QueryRowContext(c, "select 2+2").Scan(&value)

 if err != nil {

  return nil, datasource.ErrorDB{Err: err, Message: "error from sql db"}

 }

// retrieving value from Redis

 _, err = c.Redis.Get(c, "test").Result()

 if err != nil && !errors.Is(err, redis.Nil) {

  return nil, datasource.ErrorDB{Err: err, Message: "error from redis db"}

 }

return value, nil

}

Implementing Publisher-Subscriber architecture with ease:

GoFr simplifies Pub/Sub by offering built-in support for popular clients like Kafka, Google Pub/Sub, and MQTT. This eliminates the need for manual configuration or library management, allowing you to focus on your event-driven architecture. Publishing and subscribing to events are streamlined using the GoFr context. Publishing events can be done inside the handler using the context, and to subscribe to an event, you just need to use GoFr's Subscribe handler. This approach promotes clean code and reduces boilerplate compared to implementing the Pub/Sub pattern from scratch.

Example of using Publisher and Subscriber in a GoFr application:



package main

import (

 "encoding/json"

"gofr.dev/pkg/gofr"

)

func main() {

 app := gofr.New()

app.POST("/publish-product", product)

// subscribing to products topic

 app.Subscribe("products", func(c *gofr.Context) error {

  var productInfo struct {

   ProductId string json:"productId"

   Price     string json:"price"

  }

err := c.Bind(&productInfo)

  if err != nil {

   c.Logger.Error(err)

return nil

  }

c.Logger.Info("Received product ", productInfo)

return nil

 })

app.Run()

}

func product(ctx *gofr.Context) (interface{}, error) {

 type productInfo struct {

  ProductId string json:"productId"

  Price     string json:"price"

 }

var data productInfo

// binding the request data to productInfo struct

 err := ctx.Bind(&data)

 if err != nil {

  return nil, err

 }

msg, _ := json.Marshal(data)

// publishing message to producst topic using gofr context

 err = ctx.GetPublisher().Publish(ctx, "products", msg)

 if err != nil {

  return nil, err

 }

return "Published", nil

}

Out of the Box Observability:

Effective monitoring is crucial for maintaining high-performing microservices. GoFr takes the burden off your shoulders by providing built-in observability features. This eliminates the need for manual configuration of tracing, metrics, and logging libraries.

Detailed Logging: GoFr offers structured logging with various log levels (INFO, DEBUG, WARN, ERROR, FATAL) to capture application events at different granularities. This empowers you to analyze application flow, identify potential issues, and streamline debugging.
Actionable Metrics: GoFr automatically collects and exposes application metrics, allowing you to monitor key performance indicators. With metrics readily available, you can quickly identify bottlenecks and optimize application performance.
Distributed Tracing: GoFr integrates with popular tracing backends like Zipkin and Jaeger. Distributed tracing allows you to visualize the entire request lifecycle across your microservices, making it easier to pinpoint the root cause of issues within complex systems.

These observability features help users gain detailed insights into the application's flow and performance, identify and resolve bottlenecks, and ensure smooth operation.

5. Effortless Interservice HTTP Communication:

In a microservices architecture, efficient and reliable communication between services is crucial. GoFr simplifies this process by providing a dedicated mechanism to initialize and manage interservice HTTP communication. You can easily register downstream services at the application level using the AddHTTPService method.

Configurational Options for HTTP Services:

GoFr offers a variety of configuration options to enhance interservice communication:

Authentication: Supports APIKeyConfig, BasicAuthConfig, and OAuthConfig for secure authentication.
Default Headers: Allows setting default headers for all downstream HTTP service requests.
Circuit Breaker: Enhance service resilience with built-in circuit breaker functionality. GoFr allows you to configure thresholds and intervals to gracefully handle failures and prevent cascading outages.
Health Checks: Proactively monitor the health of your downstream services using GoFr's health check configuration. Define a health endpoint for each service, and GoFr will automatically verify their availability, allowing for early detection of potential issues.

These features ensure that interservice communication is secure, reliable, and easily manageable.

Example of connecting to a HTTP Service and sending a GET request:



func main() {

 a := gofr.New()

a.AddHTTPService("cat-facts", "https://catfact.ninja",

  &service.CircuitBreakerConfig{

   Threshold: 4,

   Interval:  1 * time.Second,

  },

  &service.HealthConfig{

   HealthEndpoint: "breeds",

  },

 )

a.GET("/fact", Handler)

a.Run()

}

func Handler(c *gofr.Context) (any, error) {

 var data = struct {

  Fact   string json:"fact"

  Length int    json:"length"

 }{}

var catFacts = c.GetHTTPService("cat-facts")

resp, err := catFacts.Get(c, "fact", map[string]interface{}{

  "max_length": 20,

 })

 if err != nil {

  return nil, err

 }

b, _ := io.ReadAll(resp.Body)

 err = json.Unmarshal(b, &data)

 if err != nil {

  return nil, err

 }

return data, nil

}

Flexible Middleware Support for Enhanced Control:

Middleware allows you intercepting and manipulating HTTP requests and responses flowing through your application's router. Middlewares can perform tasks such as authentication, authorization, caching etc. before or after the request reaches your application's handler.

GoFr empowers developers with middleware support, allowing for request/response manipulation and custom logic injection. This provides a powerful mechanism to implement cross-cutting concerns like authentication, authorization, and caching in a modular and reusable way. Middleware functions are registered using the UseMiddleware method on your GoFr application instance.

Additionally, GoFr includes built-in CORS (Cross-Origin Resource Sharing) middleware to handle CORS-related headers.

Example of adding a custom middleware to GoFr application:



import (

    "net/http"

<span class="n">gofrHTTP</span> <span class="s">"gofr.dev/pkg/gofr/http"</span>



)

// Define your custom middleware function

func customMiddleware() gofrHTTP.Middleware {

    return func(inner http.Handler) http.Handler {

        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {

            // Your custom logic here

            // For example, logging, authentication, etc.

        <span class="c">// Call the next handler in the chain</span>
        <span class="n">inner</span><span class="o">.</span><span class="n">ServeHTTP</span><span class="p">(</span><span class="n">w</span><span class="p">,</span> <span class="n">r</span><span class="p">)</span>
    <span class="p">})</span>
<span class="p">}</span>



}

func main() {

    // Create a new instance of your GoFr application

    app := gofr.New()

<span class="c">// Add your custom middleware to the application</span>
<span class="n">app</span><span class="o">.</span><span class="n">UseMiddleware</span><span class="p">(</span><span class="n">customMiddleware</span><span class="p">())</span>

<span class="c">// Define your application routes and handlers</span>
<span class="c">// ...</span>

<span class="c">// Run your GoFr application</span>
<span class="n">app</span><span class="o">.</span><span class="n">Run</span><span class="p">()</span>



}

Integrated Authentication Mechanisms:

Securing your microservices with robust authentication is crucial. GoFr streamlines this process by providing built-in support for various industry-standard authentication mechanisms. This empowers you to choose the approach that best suits your application's needs without writing complex authentication logic from scratch.

Basic Auth: Basic auth is the simplest way to authenticate your APIs. It's built on HTTP protocol authentication scheme. It involves sending the prefix Basic trailed by the Base64-encoded <username>:<password> within the standard Authorization header. GoFr offers two ways to implement basic authentication i.e. using pre-defined credentials as well as defining a custom validation function.
API Keys Auth: API Key Authentication is an HTTP authentication scheme where a unique API key is included in the request header for validation against a store of authorized keys. GoFr offers two ways to implement API Keys authentication i.e. Framework Default Validation as well as defining a Custom Validation Function.
OAuth 2.0: OAuth 2.0 is the industry-standard protocol for authorization. It focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. It involves sending the prefix Bearer trailed by the encoded token within the standard Authorization header. GoFr supports authenticating tokens encoded by algorithm RS256/384/512.

Refer to the GoFr's Authentication Documentation to see the examples of how to use these auth mechanisms and know more about it.

---

Automatic Swagger UI Rendering:

Providing clear and interactive API documentation is essential for user adoption and efficient development workflows. API specifications can be written in YAML or JSON. The format is easy to learn and readable to both humans and machines. The complete OpenAPI Specification can be found on the official Swagger website.

GoFr supports automatic rendering of OpenAPI (also known as Swagger) documentation. This feature allows you to easily provide interactive API documentation for your users. To allow GoFr to render your OpenAPI documentation, simply place your openapi.json file inside the static directory of your project. GoFr will automatically render the Swagger documentation at the /.well-known/swagger endpoint.

Conclusion

Throughout this article, we've explored the rich features of GoFr, an opinionated Golang framework specifically designed to accelerate microservice development. We've seen how GoFr simplifies common tasks like configuration management, database interactions, Pub/Sub integration, automatic observability, interservice communication, middleware usage, and authentication. Additionally, GoFr offers built-in support for data migrations, web sockets, cron jobs, and remote log level changes, further streamlining your development process.

We benchmarked GoFr against other popular Go frameworks such as Gin, Chi, Echo, and Fiber, and found that GoFr performed optimally, even with its extensive feature set. This means you can leverage all its powerful functionalities without compromising on performance.

We encourage you to explore GoFr for yourself. The framework's comprehensive documentation, tutorials, and active community are valuable resources to guide you on your journey. With GoFr, you can focus on building robust, scalable, and efficiently managed microservices, freeing you to dedicate more time to your application's core functionalities.

Get started with GoFr today!

Here are some helpful resources:

GoFr Website: https://gofr.dev
GoFr GitHub Repository: https://github.com/gofr-dev/gofr
GoFr Discord Server: https://discord.gg/zyJkVhps

Understanding and Utilizing Context in Go and GoFr

Umang Mundhra — Wed, 03 Jul 2024 06:52:46 +0000

What is Context?

In Go, the context package is a fundamental tool designed to manage and share request-scoped data, cancellation signals, and timeouts or deadlines across different layers of an application.
The context.Context type provides a way to carry deadlines, cancellation signals, and other request-scoped values in a chainable, hierarchical manner. It is designed to be immutable, which means that each new derived context carries the properties of its parent context while adding new values or behaviours.
Imagine a context as a special carrier bag that holds all the necessary information and instructions for a specific task. This bag can be passed from function to function, ensuring everyone involved has the same context (information) and can act accordingly. It can also contain a self-destruct button (cancellation signal) to stop the operation if needed.

Why do we need Context?

Before the introduction of Context in Go, managing request-scoped data and cancellation signals was a cumbersome task. Developers had to rely on ad-hoc solutions, such as passing around custom structs or using global variables, to share data and signals between functions and goroutines. However, these approaches were error-prone, hard to maintain, and often led to tight coupling between components.
The need for a Context arises from the fact that many operations in a program are asynchronous, concurrent, or dependent on external systems. In such cases, it's essential to have a way to propagate cancellation signals, deadlines, and request-scoped data across multiple functions and goroutines.

Let's consider a few scenarios to illustrate the need for a Context:

1. The Restaurant Analogy

Imagine you're the person taking orders in a bustling restaurant. When an order arrives, you assign it to one of your skilled cooks. But what if the customer suddenly decides to leave? Without hesitation, you'd inform the chef to stop processing that order to avoid wasting ingredients. This scenario mirrors how context works in Go.

Cancellation Propagation: In the restaurant analogy, the customer leaving corresponds to a cancellation signal. Similarly, in Go, context allows graceful propagation of cancellation signals. When a parent operation (e.g., an HTTP request handler) cancels, all related child operations (e.g., database queries or API calls) terminate promptly. This prevents resource leaks and ensures efficient cleanup.

2. Handling Slow APIs and Timeouts

Suppose your application makes web requests to external APIs or runs system commands. In production-grade systems, it's essential to set timeouts. Here's why:

API Dependency: Imagine your service relies on an external API. If that API is running slowly or becomes unresponsive, you wouldn't want your system to back up with pending requests. A timeout ensures that if the API call exceeds a specified duration, the associated context cancels, allowing your application to gracefully handle the situation.
Performance Degradation: Without timeouts, slow external
dependencies can lead to a cascading effect. Backlogged requests increase load, degrade performance, and impact overall system responsiveness. By using context with deadlines, you can prevent this issue.

Uses of Context:

The context package in Go is versatile and used in various scenarios to manage request-scoped data, cancellation signals, and timeouts.

Here are some common real-world use cases:

1. Propagating Trace IDs Across Distributed Services
In a microservices architecture, tracing requests across different services is crucial for monitoring and debugging. The context package allows you to propagate trace IDs and other metadata across service boundaries, ensuring consistent logging and tracing information throughout the request's lifecycle.

2. Passing Authentication Tokens
In many applications, authentication tokens or user information needs to be passed through different layers of the application. The context package provides a clean way to handle this, ensuring that authentication information is available where needed without polluting function signatures with additional parameters.

3. WebSocket and Streaming APIs
In WebSocket and streaming APIs, Context is used to manage the lifetime of the connection and propagate request-scoped data, such as the user ID and session information. This allows you to implement features like authentication, rate limiting, and session management efficiently.

Different Types of Context in Go:

The context package in Go offers several ways to create and manipulate context objects. Here's a breakdown of the commonly used types:

1. Background Context/TODO Context

This is the most basic context and serves as an empty starting point. It doesn't carry any cancellation signal or deadline. Use it when no specific context is required.
The only time TODO is used instead of Background is when the implementation is unclear, or the context is not yet known.

Typically used in main functions, initialization, and tests.

ctx := context.Background() ctx2 := context.TODO()

2. context.WithCancel

Creates a new context derived from a parent context., WithCancel method returns a copy of the parent context along with a cancel function; invoking the cancel function releases resources connected with the context and should be called as soon as operations in the Context type are finally completed.

Used to cancel operations in a goroutine when certain conditions are met.

parentCtx := context.Background() ctx, cancel := context.WithCancel(parentCtx) defer cancel() // Clean up resources

3. context.WithDeadline

Similar to setting a deadline for oneself, you can set a deadline for context. Go will automatically cancel the context for you if the time limit you specified for it to finish is reached. It creates a new context derived from a parent context with a specific deadline.

Useful when you have a specific deadline for completing an operation.

parentCtx := context.Background() deadline := time.Now().Add(10 * time.Second) ctx, cancel := context.WithDeadline(parentCtx, deadline) defer cancel() // Clean up resources

4. context.WithValue

Creates a new context derived from a parent context with an associated key-value pair. This allows you to store and retrieve request-specific information within the context. WithValue accepts a parent context and returns a context copy. As a result, rather than overwriting the value, it creates a new duplicate with a new key-value pair.

Useful for passing request-scoped data through the context, such as authentication tokens or trace IDs.

parentCtx := context.Background() userIDKey := "auth-token" ctx := context.WithValue(parentCtx, userIDKey, "abc123")

5. context.WithTimeout

Creates a context with an associated timeout. The context cancels automatically after the specified duration. WithTimeout, allows a program to continue where it might otherwise hang, giving the end user a better experience. It accepts a brief period as a parameter, along with the parent context, and terminates the function if it runs beyond the timeout period.

Useful for setting deadlines on operations.

parentCtx := context.Background() ctx, cancel := context.WithTimeout(parentCtx, 5*time.Second) defer cancel() // Clean up resources

GoFr Context: Supercharged Context for Go Applications

Now that we've explored the power of context in Go, let's delve into how GoFr takes it a step further with GoFr Context.

GoFr is an opinionated microservices development framework built on top of Go. It aims to streamline the development process by providing a structured approach to building robust and scalable microservices.

GoFr Context beautifully extends the functionality of the standard Go context package by creating a wrapper around it. This wrapper provides a rich set of pre-configured dependencies directly accessible through the context object. This fully loaded context enables developers to seamlessly access logging, database connections, underlying services, traces, and metrics - all from a single context object.

Example

func MyHandler(c *gofr.Context) (interface{}, error) {
  // Logging
  c.Info("Processing request...")

  // Database access
  var value int
  err := c.SQL.QueryRowContext(c, "select 2+2").Scan(&value)
  if err != nil {
    return nil, datasource.ErrorDB{Err: err, Message: "error from sql db"}
  }

  // Accessing another service
  resp, err := c.GetHTTPService("anotherService").Get(c, "book", nil)
  if err != nil {
    return nil, err
  }

  // Creating a tracing span
  span := c.Trace("some-sample-work")
  defer span.End()
  // ... perform some work

  return value, nil
}

In this example, notice how we can access functionalities like logging (c.Info), database interaction (c.SQL), service calls (c.GetHTTPService), and tracing (c.Trace) directly through the GoFr Context object (c).

The GoFr context is available in all HTTP handlers, greatly improving the development experience by providing a centralized way to manage different aspects of the application. This integration ensures that developers can focus on business logic while leveraging GoFr's capabilities for effective context management.

Conclusion

When it comes to program design, the Golang context package is an extremely useful tool. Context in Go serves as a powerful tool for managing request-scoped data, cancellation signals, and deadlines. Whether you're building microservices, APIs, or web applications, context ensures clean resource handling and consistent behaviour.

Do checkout GoFr and it's Github Repo and support it by giving it a ⭐.

WebSockets in Go and GoFr

Umang Mundhra — Fri, 28 Jun 2024 06:26:59 +0000

The Evolution of Real-Time Communication: A Brief History

In the early days of web development, achieving real-time communication between clients and servers was a challenge. Developers had to rely on methods like HTTP polling, which often caused blocks on the server, leading to delays and frustrations for both developers and users. This method involved repeatedly asking the server if there were any updates, which was inefficient and resource intensive. Then came HTTP long polling and AJAX which improved the situation but still had limitations, especially in building truly real-time applications. The real breakthrough came in 2008 with the introduction of WebSockets. This innovative technology provided an effective and straightforward solution for real-time communication. WebSockets revolutionized the way we build real-time apps, making it easier and more efficient to create dynamic, interactive web applications.

What are WebSockets?

WebSocket is a computer communications protocol that provides full-duplex communication channels over a single TCP connection. Unlike HTTP polling, which uses half-duplex communication, WebSocket allows both the server and the client to transmit and receive data simultaneously without being blocked. This reduces overhead and provides a more efficient way to maintain a continuous connection between the client and server. Data can be transferred from the server without a prior request from the client, allowing messages to be passed back and forth and keeping the connection open until the client or server kills it. Thus, a two-way real-time data transfer can take place between the client and the server. WebSocket communications are usually done via TCP port number 443.

WebSockets can sustain a connection for a longer period than most other methods, enabling real-time data transfer and keeping the connection open until either the client or server terminates it. Detailed information about the WebSocket protocol can be found in the Internet Engineering Task Force (IETF) RFC 6455 specification.

WebSocket Use-Cases and Examples:

WebSockets enjoy widespread support across platforms like Android, iOS, web browsers, and desktop applications. This versatility makes them a valuable tool for building real-time features across devices. Here are some real-world use case examples for websockets:

WhatsApp Web: Connects to your phone via WebSockets, enabling instant messaging, status updates, and real-time interactions.
GitHub Pull Requests: WebSockets keep the conversation open, allowing real-time updates on comments and changes without page refreshes.
Real-Time Tracking Applications: Ride-sharing and delivery apps leverage WebSockets for real-time location updates on drivers or deliveries.
Stock Tickers and Financial Dashboards: WebSockets facilitate displaying live stock prices and real-time updates on financial dashboards.
Audio/Video Chat (WebRTC): WebSockets play a role in enabling real-time audio and video communication through WebRTC technology.

WebSockets vs. HTTP: Understanding the Contrastst

Both HTTP and WebSockets are communication protocols that facilitate data exchange between a client and a server. However, they serve distinct purposes and operate in fundamentally different ways.
HTTP (Hypertext Transfer Protocol) follows a well-established request-response cycle. The client initiates a request, the server processes it, and sends a response back to the client. HTTP connections are short-lived. Each request establishes a connection, the server sends a response, and the connection closes. Each request from a client to the server is independent of any previous requests. This statelessness simplifies the design of web servers but can make certain types of communication inefficient. HTTP messages consist of headers and a body. The headers contain metadata about the message (such as content type and length), while the body contains the actual data being transferred.

WebSockets establish a persistent, two-way connection between client and server. Both parties can send and receive data simultaneously, enabling real-time data flow. Unlike HTTP's short-lived connections, WebSockets remain open until either client or server terminates them. This persistent connection facilitates efficient real-time communication. Data can be sent from server to client without prior client requests, enabling immediate updates and interactions.
In essence, HTTP excels at reliable request-response communication for static content retrieval. WebSockets, on the other hand, shine in real-time scenarios where continuous two-way data exchange is crucial.

How WebSockets Work: Behind the Scenes of Real-Time Communication

WebSockets start as a standard HTTP request and response, but then transition into a persistent, full-duplex communication channel. Here's how this process unfolds:

1. The WebSocket Connection Open Handshake

WebSocket URIs use the scheme ws: (or wss: for a secure WebSocket). The structure of the URI is similar to an HTTP URI, consisting of a host, port, path, and any query parameters. The connection begins with the client initiating an HTTP GET request with specific headers, including:
Upgrade: This header is set to websocket.
Sec-WebSocket-Key: This header contains a randomly generated base64 encoded key.

The server responds to this request. If it is able to upgrade the connection, it sends back a response with an HTTP 101 Switching Protocols status code, indicating that it is switching to the WebSocket protocol as requested. This response includes headers such as:
Upgrade: Confirming the upgrade to websocket.
Sec-WebSocket-Accept: A base64 encoded string, which is the server's response to the client's Sec-WebSocket-Key.

Once this handshake is successfully completed, the connection is upgraded, and both client and server switch to the WebSocket protocol.

2. The WebSocket Protocol

WebSocket is a framed protocol, which means that data is sent in discrete chunks called frames. Each frame consists of a header and a payload. The header contains information about the frame, including:
Opcode: This field indicates the type of frame (e.g., text, binary, control).
Payload Length: This field specifies the size of the payload.
Fragmentation Information: This indicates whether the frame is part of a larger message.

The frames are categorized by their opcode into types such as text frames, binary frames, and control frames (for connection management). This structure allows both the client and the server to interpret and process the data efficiently.

3. Closing the connection

To close a WebSocket connection, a closing frame is sent (opcode 0x08). In addition to the opcode, the close frame may contain a body that indicates the reason for closing. If either side of a connection receives a close frame, it must send a close frame in response, and no more data should be sent over the connection. Either party can initiate closing the connection by sending a Close control frame with a specific status code (e.g., 1000 for normal closure). Once the close frame has been received by both parties, the TCP connection is torn down. The server always initiates closing the TCP connection.

Using WebSockets in Go and GoFr:

What is GoFr?

GoFr is a comprehensive Golang framework designed to simplify web application development by providing a rich set of features, including built-in support for WebSockets. This makes it easy to build real-time applications with minimal setup and configuration.

Getting Started with GoFr WebSockets:

Using GoFr WebSockets is straightforward. Here's the basic flow:
Define a WebSocket Handler: Create a function to handle incoming WebSocket connections. This function will receive messages from the client and can send responses back.

Register the Handler with GoFr: Use the app.WebSocket method to associate your handler function with a specific endpoint (URL path) on your GoFr application.

That's it! GoFr takes care of the underlying WebSocket handshake and message framing, allowing you to focus on your application logic.
Let's Code:

package main

import (
 "fmt"

 "gofr.dev/pkg/gofr"
)

type Message struct {
 Content string `json:"content"`
 User    string `json:"user"`
}

func main() {
 app := gofr.New()

 app.WebSocket("/chat", ChatHandler)

 app.Run()
}

func ChatHandler(ctx *gofr.Context) (interface{}, error) {
 // Read the incoming message from the client
 var message Message
 err := ctx.Bind(&message)
 if err != nil {
  return nil, err
 }

 // Process the message (e.g., broadcast to all connected clients, save it to a database, etc.)
 ctx.Infof("Received message from %s: %s\n", message.User, message.Content)

 // You can send data back to the client here (optional)

 return nil, nil
}

In this example, We define a Message struct to represent chat messages. The ChatHandler function reads the incoming message using ctx.Bind. GoFr automatically detects the message format (JSON in this case) and unmarshals it into the Message struct. You can process the received message (e.g., broadcast it to all connected clients). Sending data back to the client is also possible within the handler function.

When you run the above code and try to send a message to the server using Postman:

You get these logs at the console where GoFr server is running:

Conclusion

In this article, we delved into the evolution of real-time communication from the days of HTTP polling to the modern era of WebSockets. We explored the fundamental differences between HTTP and WebSocket protocols, emphasizing how WebSockets provide a robust solution for real-time, bidirectional communication.
WebSockets have become an essential tool for building dynamic and responsive applications, from chat applications and real-time notifications to live updates and beyond. With GoFr, you have the tools to leverage this technology efficiently, ensuring your applications are both performant and maintainable.
We encourage you to explore GoFr and its WebSocket capabilities further, as it can significantly enhance your development experience and the performance of your real-time applications.

Do checkout GoFr and it's Github Repo and support it by giving it a ⭐.

Example Code Link: https://github.com/Umang01-hash/Medium-Articles/tree/main/WebSockets

Thank you for reading, Happy coding,!

Let's Explore GoFr

Umang Mundhra — Tue, 07 Nov 2023 10:01:32 +0000

Hey Guys!
Hope you all are doing great.I am happy to share will you all our newly opensourced Golang framework GoFr (https://gofr.dev/)

🚀 Introducing GoFr - An Opinionated Go Framework For accelerated microservice development! 🔥

🔗 Get started with GoFr now: https://github.com/gofr-dev/gofrJoin our Go community and supercharge your Go projects with GoFr! 🚀

I would request you all to please use/explore our new framework and support the new forming GoFr community.🙏🏻

Consider giving it a 🌟 if you like the framework.🙂