I added SSO to every app in my homelab. The Terraform code is boring; the gotchas are interesting. Here’s everything that bit me, in the order it bit me.

My service was slow at 28ms per request. I could have guessed the cause - database, JSON, strings? Instead, I profiled it. The results surprised me.

I spent two weeks optimizing a function that accounted for 0.3% of my program’s runtime. Meanwhile, a JSON call was eating 45% of CPU. pprof would have shown me in seconds.

Introduction

In the Go programming ecosystem, developers have a plethora of libraries available for solving common problems. However, some libraries may not always be the best fit for every project or developer preference. This article highlights a few Go libraries that I personally avoid using, along with the reasons behind these choices. The intention is not to discourage the use of these libraries universally but to shed light on potential challenges that may arise when using them, especially in larger or more complex projects.

Introduction

In this blog post, I want to share my approach to testing functions involving randomness in Go. Recently, I was asked how I would test a specific function that calculates possible directions for an object to move. Initially, I didn’t come up with a good idea. Here, I’ll discuss how I’d solve this problem in a real-world application with a detailed explanation.

The Function in Question

The function calculates all possible directions that an object can move (up, down, left, right) without violating boundaries. It then randomly selects a valid direction and returns the new coordinates.

Are you looking to dive into the world of Kubernetes and enhance your dev skills? Whether you’re gearing up for the Certified Kubernetes Application Developer (CKAD) exam or simply eager to experiment with Kubernetes, having your own cluster is invaluable. However, setting up a Kubernetes cluster for practice can be a daunting task, especially when the available options either fall short of expectations or are too complex for learning purposes.

The best to hash passwords in Go is using golang.org/x/crypto/bcrypt:

func HashPassword(password string) (string, error) {
    bytes, err := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
    return string(bytes), err
}
  
func CheckPasswordHash(password, hash string) bool {
    err := bcrypt.CompareHashAndPassword([]byte(hash), []byte(password))
    return err == nil
}

You should use the default bcrypt.DefaultCost just in case that the current value will become not sufficient and the default cost will increase.

We can trace NodeJS GC by using

  node --trace-gc app.js

And use the performance tool to get the data in runtime.

  const { PerformanceObserver } = require('perf_hooks');
  
  // Create a performance observer
  const obs = new PerformanceObserver((list) => {
    const entry = list.getEntries()[0]
    /* 
    The entry would be an instance of PerformanceEntry containing
    metrics of garbage collection.
    For example:
    PerformanceEntry {
      name: 'gc',
      entryType: 'gc',
      startTime: 2820.567669,
      duration: 1.315709,
      kind: 1
    }
    */
  });
  
  // Subscribe notifications of GCs
  obs.observe({ entryTypes: ['gc'] });
  
  // Stop subscription
  obs.disconnect();

To gather memory usage we can use the following code

Creating an organized code structure can be a complex endeavor. Previously, I penned a blog post entitled How to structure Go code?, an attempt to demystify this topic. While I stand by the insights shared, I’ve come to realize that the article is somewhat generic and lacks clear, tangible answers to the question at hand.

There’s arguably no better way to understand such concepts than by diving into concrete examples. Today, I’d like to discuss the evolution of a package named productcatalog and explain why I chose to streamline its structure.

I’m excited to share with you my new project - an open-source e-commerce platform. The frontend is built with ReactJS and the backend is written in Go.

Project Goals

The goal of this project is to:

• Continuously improve and develop the platform.
• Provide an opportunity for less experienced programmers to gain experience working on a real project.
• Experiment with various methodologies and tools that may not be available in other work settings (event-driven architecture, DDD, event sourcing, and more).
• Build an application from scratch, including the entire ecosystem (frontend, backend, database, infrastructure, monitoring, observability).

Good Development Practices

Additionally, I strive to follow best practices in software development, such as writing Architecture Decision Records (ADRs) and thorough documentation. I believe that these practices help ensure the long-term success of the project and facilitate collaboration among contributors.