Forem: Aryan Mehrotra

The Microservices Backlash: Over-Engineering or Misunderstood Architecture?

Aryan Mehrotra — Tue, 29 Apr 2025 22:49:45 +0000

Introduction

Microservices architecture has been one of the most debated topics in software engineering over the past decade. While many organizations have successfully adopted this pattern, there's growing skepticism about whether microservices are often an over-engineered solution to problems that could be solved with simpler architectures. This article explores why microservices generate so much criticism, examines valid concerns about over-engineering, and presents alternative approaches like clean three-layer architecture that might offer better solutions for many projects - with a powerful ally that simplifies it.

TL;DR Skip to the end to meet the ally... but if you do, you'll miss:

Why your Kubernetes cluster gives you nightmares
How foreign keys became the villains of our story
The secret monolith-master race manifesto
Why 90% of microservices are just distributed monoliths in disguise

Why People Hate Microservices

1. Complexity Overhead

Microservices introduce significant operational complexity that many teams aren't prepared to handle. Suddenly, you need to manage:

Service discovery
Distributed tracing
Circuit breakers
API gateways
Cross-service transactions
Eventual consistency patterns

For small to medium-sized applications, this complexity often outweighs the benefits.

"We spent 3 months setting up observability before writing business logic" – Anonymous Engineer

2. Infrastructure Costs

The criticism about Kubernetes costs is valid for many cases. Running multiple services in production requires:

Container orchestration
More sophisticated monitoring
Additional network infrastructure
Potentially more expensive hosting solutions

While you can run microservices on a single EC2 instance, this often defeats the purpose of having independent scalability.

3. Development Experience Degradation

Developers frequently complain about:

Needing to run multiple services locally
Difficulty in debugging distributed systems
More complicated CI/CD pipelines
Context switching between multiple codebases

4. Premature Scaling

Many teams adopt microservices because "we might need to scale," not because they actually need to scale. This premature optimization leads to unnecessary complexity.

The Over-Engineering Problem

Microservices have become a victim of their own hype cycle. Many teams implement them because:

Resume-driven development ("FAANG uses them!")
Architecture theater (Impressive-looking diagrams)
Premature optimization ("We might need to scale someday")

Reality Check:

Less than 5% of applications truly benefit from microservices initially.
Rarely do teams honestly assess whether their problem actually requires a distributed systems approach. The truth is that most applications never reach the scale where monoliths become problematic, and when they do, careful modularization within a monolith can often solve the scaling issues.

Modular Monoliths: The Balanced Approach

Your observation about structuring code for potential future separation is insightful. This approach—often called the "modular monolith" pattern—provides many benefits:

Single codebase: One repository with clear internal boundaries
Simplified deployment: One binary/Docker image to manage
Easier testing: No need for complex integration test setups
Future flexibility: Well-structured code can be split later if truly needed

In Go, this could look like:

/project
├── main.go          # Single entry point
├── order/           # Fully self-contained
│   │   ├── handler/
│   │   ├── service/
│   │   └── store/
│   ├── main.go      # Optional microservice entry point
│   └── Dockerfile   # Optional microservice Dockerfile
│-── catalogue/      # Independent domain
│-─  customer/       # Clear boundaries
└── Dockerfile       # Single deployment

Key Architectural Decisions

1. Domain-Centric Organization

This structure organizes code by business domains (order, catalogue, customer) rather than by technical layers (controllers, services, repositories). Each domain contains its own complete vertical slice of the architecture.

Benefits:

Better alignment with business capabilities
Reduced cross-domain coupling
Easier to extract into microservices later if needed
More cohesive code organization

2. Self-Contained Modules

Each domain module contains:

Handler: HTTP/API delivery layer
Service: Business logic layer
Store: Data access layer

This follows the principles where:

Dependencies flow inward (handlers depend on services, services depend on stores)
Outer layers can be swapped without changing inner layers
Business logic remains agnostic

3. Flexible Deployment Options

The structure supports multiple deployment strategies:

Monolithic Mode:

Single main.go orchestrates all domains
Unified configuration
Single process monitoring

Microservice Mode:

Any service can be built and deployed separately using its own main.go and Dockerfile

Advantages Over Traditional Three-Layer

Better Domain Isolation: Clear boundaries prevent accidental coupling
Easier Testing: Each domain can be tested in isolation
Progressive Complexity: Start simple, add distribution only when needed
Team Scalability: Different teams can own different domains

When This Works Best

This architecture shines when:

You want to avoid microservices overhead but maintain separation
Your team is small-to-medium sized
You might need microservices eventually but not yet
Different domains have different evolution speeds

The key insight is that code organization doesn't have to match deployment topology. You can maintain clean separation in code while deploying as a monolith, then change deployment strategy later without massive rewrites.

Clean Three-Layer Architecture in Practice

1. Delivery Layer (Handler)

Receives HTTP requests
Handles:
- Request validation
- Authentication/authorization
- Error formatting
- Response marshaling
Should be thin - delegates business logic to service layer
Example:

  type service interface {
      CreateOrder(ctx *gofr.Context, order Order) (error)
  }

  func (h *OrderHandler) Create(c *gofr.Context) (any,error) {
      var req OrderRequest

      if err := c.Bind(&req); err != nil {
          return nil,http.ErrorInvalidParam{Params: []string{"body"}}
      }

      // Delegates to service layer
      return nil, h.service.CreateOrder(ctx, req)
  }

2. Business Logic Layer (Service)

Manages all domain relationships
Database-agnostic (critical for flexibility)
Anti-pattern alert:

  -- ❌ Avoid foreign key constraints
  CREATE TABLE orders (
      customer_id INT REFERENCES customers(id)  # Tight DB coupling
  );

Why? Database-level constraints like foreign keys create tight coupling that violates service boundaries - always enforce relationships in your application code, not your storage layer.

Contains domain logic
Orchestrates multiple store operations
Enforces business rules

Better:

  // ✅ Service manages validation
  type customerService interface {
      GetByID(ctx *gofr.Context, id string) (Customer, error)
  }

  func (s *OrderService) Create(ctx *gofr.Context,input OrderInput) error {
      exists, err := s.customerService.GetByID(ctx,input.CustomerID)
      if err != nil {
          return err
      }
      // Proceed with order creation
  }

3. Store Layer (Data Access)

Handles database operations
Manages:
- Database connections
- Query building
- Caching

Practical Microservice Division: Your E-commerce Example

Order Service: Focused purely on order processing
Catalogue Service: Manages products and brands (cohesive domain)
Customer Service: Handles all customer-related data

This division follows domain boundaries rather than technical concerns. The key insight is keeping tightly coupled entities together (like brands and products) while separating domains that can evolve independently (like orders and customers).

When Microservices Deployment Make Sense

Microservices Deployment become valuable when:

Different components have genuinely different scaling requirements
Teams need to work independently with different release cycles
You have clear domain boundaries with minimal cross-domain communication
You're at a scale where operational overhead is justified

Conclusion

The backlash against microservices stems from their frequent misuse as a default architecture rather than a deliberate choice for specific scaling needs. For most applications—especially early-stage products—starting with a well-structured modular monolith using clean architectural principles provides better velocity and maintainability.

The wisdom in your approach lies in recognizing that code organization and deployment strategy are separate concerns. You can structure your code for potential future distribution while maintaining the simplicity of a monolith deployment. This pragmatic approach avoids over-engineering while preserving architectural flexibility for when (and if) you truly need to scale.

Final Insight:

"Good architecture maximizes options, not complexity."

With GoFr, you get:

Simplicity when you need it
Scalability when you require it
Sanity throughout your journey

Explore GoFr to build systems that grow with your needs, not your headaches.

Unlocking Hidden Performance Bottlenecks in Golang using GoFr: The Underrated Power of pprof

Aryan Mehrotra — Wed, 26 Mar 2025 21:14:45 +0000

In high-traffic production environments, unexpected performance bottlenecks can degrade user experience and threaten system reliability. While GoFr, a powerful Golang framework, offers built-in observability, some issues demand deeper debugging to pinpoint the exact lines of code causing slowdowns. This is where pprof—an underrated yet potent tool—shines, delivering real-time performance profiling and actionable insights.

The Challenge of Debugging Performance Issues in Golang

Golang services are built for speed, but at scale, even small inefficiencies can snowball into significant performance hits. Debugging these issues is tricky because:

Traditional logs and traces provide historical data but can’t capture real-time bottlenecks.
Problems like CPU spikes, memory leaks, and goroutine contention require live profiling to diagnose effectively.
Many profiling tools demand complex setup or risk destabilizing production environments.

How GoFr & pprof Solve This Quickly

GoFr simplifies observability with integrated logging, monitoring, and metrics (visualizable via tools like Grafana). For deeper debugging, it pairs seamlessly with pprof, enabling developers to:

Quickly Enable Profiling: With a simple config tweak in GoFr, unlock real-time CPU, memory, and goroutine profiling.
Analyze Performance in Production: Diagnose high-latency endpoints without downtime, thanks to pprof’s runtime capabilities.
Optimize for Peak Traffic: Spot inefficient operations—like JSON decoding, mutex contention, or costly database calls—and address them proactively.

pprof in GoFr

In GoFr applications, pprof profiling is built-in and accessible via the METRICS_PORT (defaulting to 2121 if unspecified). This dedicated port isolates profiling endpoints from your main application, enhancing security. Access them at:

CPU Profiling: <host>:2121/debug/pprof/profile
Memory Profiling: <host>:2121/debug/pprof/heap
Goroutine Analysis: <host>:2121/debug/pprof/goroutine

Using data collected from these endpoints, developers can generate detailed CPU profiles and flamegraphs to visualize performance bottlenecks.

CPU Profile (Call Graph)

A CPU call graph illustrates how functions execute and interconnect at runtime:

Nodes: Represent functions.
Edges: Show function calls between them.

This view is ideal for understanding program flow and dependencies.

Flamegraph

A flamegraph highlights CPU usage visually with stacked bars:

X-axis: Function execution time (wider bars mean more time spent).
Y-axis: Call hierarchy (higher stacks indicate deeper calls).

It’s a fast way to spot performance hotspots and prioritize optimizations.

Key Differences

CPU Call Graph: Emphasizes function relationships and execution order.
Flamegraph: Pinpoints CPU-intensive functions and bottlenecks.

Real-World Use Case: Debugging Latency Spikes in a Golang Service

Imagine a Go-based service hit by latency spikes during peak traffic. Standard monitoring (logs, GoFr’s metrics in Grafana) flags high API response times, but the root cause stays elusive. A common culprit? Inefficient JSON decoding, where json.Unmarshal() chews up CPU via reflection. Without profiling, this is a needle in a haystack. Here’s how pprof saves the day:

Identify the Problem Using Grafana: GoFr’s metrics, visualized in Grafana, show elevated response times. Uneven load distribution suggests concurrency issues.
Run Real-Time Profiling with pprof: Enable pprof in GoFr with a config change. Collect CPU and memory profiles during peak load, then analyze them with go tool pprof.
Pinpoint the Bottleneck: Profiling reveals json.Unmarshal() as a CPU hog due to reflection-based unmarshaling—slowing down requests significantly.
Apply Optimizations & Measure Impact: Swap encoding/json for jsoniter (a high-performance JSON library). Cut API latency by 30%. Deploy safely with feature flags and confirm gains in Grafana.

Why This Approach Is a Game-Changer for Golang Developers

Minimal Setup: GoFr enables pprof with a single config tweak—no complex integrations.
Live Debugging Without Downtime: Profile production systems in real-time using pprof’s runtime capabilities.
Pinpoint Slow Code Paths: Uncover inefficient functions dragging down performance.
Optimize Safely: Roll out fixes with confidence using controlled deployments.

Final Thoughts

Performance debugging in Golang doesn’t have to be a mystery. By combining GoFr’s observability with pprof’s profiling power, developers can expose hidden inefficiencies and tune services for peak performance at scale.

Have you tackled JSON decoding bottlenecks with pprof—or found other sneaky slowdowns? Share your experiences in the comments! 🚀

Support GoFr by giving a ⭐: https://github.com/gofr-dev/gofr

Check out GoFr’s profiling docs: https://gofr.dev/docs/advanced-guide/debugging

Explore Golang’s official diagnostics guide: https://go.dev/doc/diagnostics

I Hated gRPC until this tool started Simplifying it!

Aryan Mehrotra — Sun, 12 Jan 2025 20:54:13 +0000

gRPC, Google’s open-source RPC framework, has become a go-to choice for building high-performance, efficient APIs. It’s fast, reliable, and ideal for microservices. But let’s be honest — getting started with gRPC can be a real headache.

From installing protoc and its plugins to managing the generated code, there’s a lot to set up before you can even write your first handler. That complexity often makes developers shy away from using it, despite its advantages.

Fortunately, GoFr can make working with gRPC significantly easier by providing built-in support for observability, dependency management, and a simplified development process.

The Challenges of Using gRPC

While gRPC is amazing, it comes with its fair share of pain points:

Steep Setup Curve Setting up the protocol buffer compiler (protoc), installing plugins, and ensuring compatibility often feels like a chore.
Manual Code Generation Defining services in .proto files and generating code requires multiple commands. Any misstep can result in errors and wasted time.
Boilerplate Code Even after generating the necessary files, writing handler code from scratch and integrating dependencies can feel overwhelming.
Lack of Integrated Tools Observability, database connections, and configuration management typically require separate efforts to integrate.

How GoFr Simplifies gRPC Development

While GoFr doesn’t replace the need for protoc, it enhances the development experience by providing seamless integration with modern tools and practices.

Key Features of GoFr for gRPC

Integrating Observability and Dependencies: Access databases, logging, metrics, traces directly from GoFr’s context.
Generating Ready-to-Use Handlers: Use the gofr wrap grpc command to scaffold handler templates for your gRPC services.
Reducing Boilerplate: Focus on business logic instead of repetitive setup tasks.

Getting Started with GoFr and gRPC

If you’re ready to explore how GoFr can simplify your gRPC workflow, here are the key resources to get you started:

Install and Use GoFr for gRPC:

Official Examples:

gRPC Server Example in GoFr

Conclusion

gRPC is a powerful framework, but its initial setup can be daunting. GoFr doesn’t eliminate the need for protoc, but it significantly reduces the friction by providing context-driven tools and simplifying the development process.

Whether you’re new to gRPC or an experienced developer, GoFr’s integration of observability and dependency management makes gRPC development more approachable and efficient.

Give it a try — you might just find yourself enjoying gRPC more than ever before!

Support GoFr by giving a ⭐: https://github.com/gofr-dev/gofr

The Ultimate Golang Framework for Microservices: GoFr

Aryan Mehrotra — Wed, 24 Jul 2024 06:55: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:

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:

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.

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"

    gofrHTTP "gofr.dev/pkg/gofr/http"
)

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

            // Call the next handler in the chain
            inner.ServeHTTP(w, r)
        })
    }
}

func main() {
    // Create a new instance of your GoFr application
    app := gofr.New()

    // Add your custom middleware to the application
    app.UseMiddleware(customMiddleware())

    // Define your application routes and handlers
    // ...

    // Run your GoFr application
    app.Run()
}

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 : 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!

Star the repo if you like it! @ https://github.com/gofr-dev/gofr

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

Runtime Log Level Change using Golang & GoFr

Aryan Mehrotra — Mon, 22 Jul 2024 07:48:20 +0000

In this article, I will be sharing how you can change the log level of your application without restarting your application.

Introduction

Log levels are usually considered to be in order of importance: turn on "unimportant" levels in development (notice, debug and the like), but enable only the "most important" levels (warn, error, etc.) in production, where resources like CPU time and disk space are precious.

But what if your application is running at ERROR level and you start facing many issues, but you cannot figure it out from ERROR level logs, changing the log level by redeploying the application will take a lot of time and resources.

Moreover, running your application at either INFO or DEBUG level in production will generate a large number of logs which can overwhelm the logging system, leading to increased I/O operations and resource consumption.

To rescue us from these issues, GoFr - The Ultimate Golang Framework provides a secure way to change the log level without restarting your application.

Changing Log Level

To change the log level any GoFr application requires the following configuration:

REMOTE_LOG_URL=<URL to user remote log level endpoint> (e.g., https://log-service.com/log-levels?id=1)

GoFr fetches the endpoint provided every 15 seconds by default to get the latest log level, this interval can be increased or decreased by adding the following configuration.

REMOTE_LOG_FETCH_INTERVAL=<Interval in seconds> (default: 15)

Log Level Service

GoFr requires the response from the URL in the following format with two mandatory fields:

{
    "data": {
       "serviceName": "test-service",
       "logLevel": "DEBUG"
    }
}

Let's create the log-level service which will provide the log-level to our application.

I will be using GoFr to create the service, refer the documentation to know more.

We will use MySQL as the database, to add MySQL add the following configs in .env file in the configs directory.

DB_HOST=localhost
DB_USER=root
DB_PASSWORD=password
DB_NAME=log-level
DB_PORT=2001
DB_DIALECT=mysql

To run the MySQL docker container run the following command

docker run --name gofr-logger -e MYSQL_ROOT_PASSWORD=password -e MYSQL_DATABASE=log-level -p 2001:3306 -d mysql:8.0.30

Lets add the main.go file with migrations to create table and we will use AddRESTHandler feature to register the route.

main.go

package main

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

const createTable = `CREATE TABLE level (
    id INT PRIMARY KEY,
    service_name VARCHAR(255) NOT NULL,
    log_level VARCHAR(50) NOT NULL
);
`

func createTableLevel() migration.Migrate {
 return migration.Migrate{
  UP: func(d migration.Datasource) error {
   _, err := d.SQL.Exec(createTable)
   if err != nil {
    return err
   }

   return nil
  },
 }
}

type Level struct {
 ID          int    `json:"id"`
 ServiceName string `json:"serviceName"`
 LogLevel    string `json:"logLevel"`
}

func (u *Level) RestPath() string {
 return "level"
}

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

 app.Migrate(map[int64]migration.Migrate{1: createTableLevel()})

 err := app.AddRESTHandlers(&Level{})
 if err != nil {
  app.Logger().Fatalf("Failed to register routes for level struct: %v", err)
 }

 app.Run()
}

After running the Log Service we will see the following logs:

We have all the REST routes registered.

To Create a service send the following request:

curl --location 'localhost:8000/level' \
--header 'Content-Type: application/json' \
--data '{
    "id":1,
    "logLevel":"INFO",
    "serviceName":"gofr-app"
}'

To Update the log level send the following request:

curl --location --request PUT 'localhost:8000/level/1' \
--header 'Content-Type: application/json' \
--data '{
    "id":1,
    "logLevel":"DEBUG",
    "serviceName":"gofr-app"
}'

To Get the log level send the following request:

curl --location 'localhost:8000/level/1'

The same URL will be used in the configs of our application whose log-level has to be changed remotely.

CONCLUSION

By using GoFr remote Log Level change feature, you will get benefits such as:

Effortless Adjustments:
Modify the log level anytime without restarting the application. This is especially helpful during troubleshooting.
Enhanced Visibility:
Easily switch to a more detailed log level (e.g., DEBUG) to gain deeper insights into specific issues, and then switch back to a less detailed level (e.g., INFO) for regular operation.
Improved Performance:
Generating a large number of logs can overwhelm the logging system, leading to increased I/O operations and resource consumption, changing to Warn or Error Level reduces the number of logs, and enhancing performance, and REDUCING CLOUD COST.

Support GoFr by giving a ⭐star: https://github.com/gofr-dev/gofr

Moreover, you have access to the free public endpoint to export and view your application's traces @ tracer.gofr.dev.
To enable it, add the following config in your .env file

TRACE_EXPORTER=gofr

Other Benefits:
If you contribute towards GOFR either in development or writing articles. You can get free swags(T-shirts, Stickers) by filling out the form presented on their GitHub Readme (at the bottom).

Released! GoFr - An Opinionated Go Framework

Aryan Mehrotra — Thu, 09 Nov 2023 20:30:40 +0000

🚀 Hey🌟
We've been on an incredible journey with GoFr, our opinionated microservice development framework and we have recently opensource it and released the version v1.0.0.

Our story with GoFr started out of necessity to tackle those cross-cutting concerns inherent in microservice development. Over the years, this framework has evolved and been used in different ways, ultimately becoming what it is today.

You can star, fork, contribute, and use GoFr in your personal or commercial projects.

Do visit and share your thoughts! 💬
Github : https://github.com/gofr-dev/gofr
Website : https://gofr.dev