Forem: BENKAY THE FIRST

Concurrency in Golang

BENKAY THE FIRST — Sun, 20 Dec 2020 19:06:01 +0000

In golang, concurrency is made possible through the use of goroutines and channels.
goroutines are basically "thread-like" lightweight structures that complete activities without blocking the main thread. They are basically a "fire and forget" cause go cleans up when a goroutine is completed. If however, we want to get data out of our goroutine process when it is done then we can use channels.

import "fmt"

// Essentially this is how we fire a goroutine

func runForAWhile(){
  // do something pretty that takes 5 secs or 2 yrs
}

func main(){
  go runForAWhile()
  fmt.Println("I am not waiting for that...")
}

Once we use the go keyword, Go knows to send the operation of that function out of the main scope and continue executing the rest of the code. The program does not end however until the goroutine is complete.
When you run the above example, you'd notice that the Println statement runs almost instantly while the program itself ends after the goroutine has supposedly ended.
Channels are an effective way to wait on output from our goroutine before ending the program. Let's say we made two API calls using two goroutines, we surely want to get that result back into the main scope. Here is an example code that describes how you could achieve that:

import "fmt"

func apiRequest1(c chan string){
  var result string
  result = makeApiCall1()
  c <- result
}

func apiRequest2(c chan string){
  var result string
  result = makeApiCall2()
  c <- result
}

func main(){
  var channel1, channel2 chan string
  go apiRequest1(channel1)
  go apiRequest2(channel2)

  result1 := <- channel1
  result2 := <- channel2

  fmt.Println(result1, result2)
}

How to write quality time-based tests in Golang

BENKAY THE FIRST — Sun, 20 Dec 2020 07:33:28 +0000

A few days ago, I decided to make a Pull Request of a feature I wrote myself for use at my company, a Rate-Limiting Middleware. Unlike other conventional middlewares in the package, rate-limiting is a really tricky one to write tests for because it requires a strictly time-based testing suite in order to test that it works as intended. Didn't seem like much to me at first. I wrote the tests and hit a 100% coverage and they all passed on my computer.

Opened a PR at Echo and noticed that on some environments, tests passed, while they failed on others. After trying to make sense of it I noticed that there was no pattern, the failure was totally random and unpredictable. I studied the source code and tried to pin the fault on a particular unit but every thing seemed flawless. That was when I tried to study the only variable factor, time. Since my tests depended on the clock of the host computer and the system ticks are subject to lags when the CPU undergoes strain, my tests will most likely fail on systems that have lower CPU power because of lags during each tick.
Here is a link to the Updated PR incase you want to see what is going on yourself:

adds middleware for rate limiting #1724

iambenkay posted on Dec 17, 2020

What's New?

This feature implements a store agnostic rate limiting middleware i.e configurable with any store of user's choice.

Here is a dummy snippet of how a certain (unconventional) redis store might be integrated with the rate limiting middleware

type RedisStore struct {
   client redis.Client
}

// Store config must implement Allow for rate limiting middleware
func (store *RedisStore) Allow(identifier) bool {
   // run logic here that decides if user should be permitted
   return true
}

func main(){
   e := echo.New()

   redisStore := RedisStore{
      client: redis.Client{}
   }
   
   limiterMW := middleware.RateLimiter(redisStore)
   e.Use(limiterMW)
}

I threw in an InMemory implementation for people like me who want to get on the go fast.

func main(){
   e := echo.New()

   var inMemoryStore = middleware.RateLimiterMemoryStore{
      rate: 1,
      burst: 3,
   }
   
   limiterMW := middleware.RateLimiterWithConfig(RateLimiterConfig{
      Store: &inMemoryStore,
      SourceFunc: func(ctx echo.Context) string {
         return ctx.RealIP()
      },
   })
   e.Use(limiterMW)
}

closes #1721

View on GitHub

So after I established that the system ticker cannot be trusted to provide a consistent tick rate enough to verify that my rate limiter works as intended, I set off to trick my tests by finding a stable time model that does not depend on the system ticker. The rest of this blog will cover the specifics.

Firstly, you'd need to wrap all usages of standard time helpers with custom functions that resolve to them. In my case the only main helper I needed to wrap was time.Now.

var now func() time.Time

now = func() time.Time {
  return time.Now()
}

Now in your source code, replace all occurrences of the now wrapped helpers with your custom helpers. The goal of this is to be able to use the original helpers in the main source code but easily mock them in the corresponding tests.

func (store *RateLimiterMemoryStore) Allow(identifier string) bool {
    store.mutex.Lock()
    limiter, exists := store.visitors[identifier]
    if !exists {
        limiter = new(Visitor)
        limiter.Limiter = rate.NewLimiter(store.rate, store.burst)
        limiter.lastSeen = now() // instead of time.Now()
        store.visitors[identifier] = limiter
    }
    limiter.lastSeen = now() // instead of time.Now()
    store.mutex.Unlock()
    if now().Sub(store.lastCleanup) > store.expiresIn {
        store.cleanupStaleVisitors()
    }
    return limiter.AllowN(now() /* instead of time.Now() */, 1)
}

Now in the context of our tests we have to change what now() returns from the standard time to our custom computed time:

func TestRateLimiterMemoryStore_Allow(t *testing.T) {
  var inMemoryStore = NewRateLimiterMemoryStore(RateLimiterMemoryStoreConfig{rate: 1, burst: 3, expiresIn: 2 * time.Second})
  testCases := []struct {
    id      string
    allowed bool
  }{
    {"127.0.0.1", true},  // 0 ms
    {"127.0.0.1", true},  // 220 ms burst #2
    {"127.0.0.1", true},  // 440 ms burst #3
    {"127.0.0.1", false}, // 660 ms block
    {"127.0.0.1", false}, // 880 ms block
    {"127.0.0.1", true},  // 1100 ms next second #1
    {"127.0.0.2", true},  // 1320 ms allow other ip
    {"127.0.0.1", false}, // 1540 ms no burst
    {"127.0.0.1", false}, // 1760 ms no burst
    {"127.0.0.1", false}, // 1980 ms no burst
    {"127.0.0.1", true},  // 2200 ms no burst
    {"127.0.0.1", false}, // 2420 ms no burst
    {"127.0.0.1", false}, // 2640 ms no burst
    {"127.0.0.1", false}, // 2860 ms no burst
    {"127.0.0.1", true},  // 3080 ms no burst
    {"127.0.0.1", false}, // 3300 ms no burst
  }

  for i, tc := range testCases {
    t.Logf("Running testcase #%d => %v", i, time.Duration(i)*220*time.Millisecond)
    // Should have been a time.Sleep here but we manually increase the value of the date that the now function returns using the iterator from the for loop.
    now = func() time.Time {
      return time.Date(2009, time.November, 10, 23, 0, 0, 0, time.UTC).Add(time.Duration(i) * 220 * time.Millisecond)
    }
    allowed := inMemoryStore.Allow(tc.id)
    assert.Equal(t, tc.allowed, allowed)
  }
}

You'd notice I am not depending on time.Sleep or the system ticker to simulate a change in time for my tests. I am flexibly computing the next time in the for loop based on the iteration count. This way tests don't have to literally wait for the system ticker to actually tick before working with it's value and since the time is computed, in reality the tests will not actually have to wait for the required number of real live seconds to complete. Brings speed back to your tests and CPU agnostic flexibility. Now you can write time-based tests that will pass regardless of the clock speed of the CPU.

Setting up a git server on your Ubuntu Server for Continous Integration

BENKAY THE FIRST — Sat, 14 Nov 2020 18:13:28 +0000

Hey there! 👋 In the spirit of modern dev practices, I am writing this blog to highlight a life saver for me. When I started out as a backend developer, I used Heroku (and still use it occasionally) which has this amazing way of automatically building and deploying your apps whenever you push to the connected git repositories. I was forced to learn how to do it myself when my work started driving me to use bare-bone machines on AWS or Digital Ocean and I would always have to SSH into the server just to manually pull from my git repo and build it on my server before deploying. Coming from a lazy perspective, this was crazy work that I wasn't ready to do each time I make a change to the app and the spirit of automation started ringing in my ears.
The words that came into my head were "GIT SERVER"! I googled to see if it was a thing and luckily it was. I finally figured out how GitHub was able to do it. So I embarked on my own journey to make my own git server.
The next few paragraphs detail how I conquered that beast;
Well you do need git installed for starters so go do that first. This article assumes you have SSH set up on your ubuntu server.

Step 1

The first thing we need to do is create a git bare repository on our server.

# incase you already have a codebase
git clone --bare remote_repo_url.git server_repo.git

# but if you wanna start from scratch you could just use init
mkdir server_repo.git && cd server_repo.git
git init --bare

A bare git repository isn't like a regular repository. It stores our git objects but not the actual source code. It's typically the .git folder in a regular repository. After that we need to create a directory on the server to store the actual source code:

mkdir server_source

Step 2

Now, from a machine that has SSH Access to your ubuntu server you'll add your bare repository as a git remote:

git remote add production <username>@<machine>:server_repo.git

# You can now push to this remote
git push production master

# Or pull from it
git pull production master

basically server_repo.git has to be the location of your bare repo on the ubuntu server while username and machine are your login details just like when logging in with SSH.

Step 3

Next is the feature that makes all this possible. GIT HOOKS! I have written about them in the past here:

How to run tests automatically on each push to the repository | by Benjamin Chibuzor-Orie | FAUN — Developer Community 🐾

Benjamin Chibuzor-Orie ・ Aug 29, 2020 ・
Medium

Feel free to check it out. So essentially the hook we would be needing is the post-receive hook.

As the name implies, It runs after (post-) git objects are received from a remote.

Below is a typical post-receive file:

#! /bin/bash

# we have to set GIT_DIR env var to the bare repo
WORK_TREE=$HOME/server_source
GIT_DIR=$HOME/server_repo.git

# next up we have to checkout from our bare repo
git --work-tree=$WORKTREE --git-dir=$GIT_DIR checkout -f

# from here on we can do any other processes like building and 
# deploying the app
cd $WORK_TREE
docker-compose up --build -d

Now all we need to do is add this file to our git hooks. In our bare repo server_repo.git we need to create a new file post-receive under the hooks folder and then store the above in it.
We also need to make it executable on linux using chmod.

chmod a+x post-receive

After this we are good to go! Anytime we push to our production remote from our local, it will run the post-receive script and deploy our app.

If you have any questions, I'll be waiting in the comment sections to deal with it 🏌️‍♂️🏌️‍♂️