DEV Community: Viet Le

Build your own X

Viet Le — Mon, 06 Jun 2022 10:42:42 +0000

If you are looking to build anything cool, I think this repo is helpful for you:
https://github.com/codecrafters-io/build-your-own-x

Build anything in your favorite languages!

Anyone on Twitter? Let's connect!

Viet Le — Thu, 02 Jun 2022 04:17:55 +0000

I feel like this community is more active for me than on Twitter. So I post here to ask if there is anyone here also on Twitter, let's connect!

My account: @vietmle_

5 concurrency patterns in Golang

Viet Le — Wed, 01 Jun 2022 00:45:47 +0000

This article will cover 5 simple concurrency patterns which are often used in Golang

1. `for-select` pattern

This is a fundamental pattern. It is typically used to read data from multiple channels.

var c1, c2 <-chan int

for { // Either loop infinitely or range over something 
    select {
    case <-c1: // Do some work with channels
    case <-c2:
    default: // auto run if other cases are not ready
    }

    // do some work
}

The select statement looks like switch one, but its behavior is different. All cases are considered simultaneously & have equal chance to be selected. If none of the cases are ready to run, the entire select statement blocks.

2. `done` channel pattern

Goroutine is not garbage collected; hence, it is likely to be leaked.

go func() {
// <operation that will block forever>
// => Go routine leaks
}()
// Do work

To avoid leaking, Goroutine should be cancelled whenever it is told to do. A parent Goroutine needs to send cancellation signal to its child via a read-only channel named done . By convention, it is set as the 1st parameter.

This pattern is also utilized a lot in other patterns.

//child goroutine
doWork(<-done chan interface {}, other_params) <- terminated chan interface{} {
    terminated := make(chan interface{}) // to tell outer that it has finished
    defer close(terminated)

    for {
        select: {
            case: //do your work here
            case <- done:
                return
        }
        // do work here
    }

    return terminated
}

// parent goroutine
done := make(chan interface{})
terminated := doWork(done, other_args)

// do sth
// then tell child to stop
close (done)

// wait for child finish its work
<- terminated

3. `or-channel` pattern

This pattern aims to combine multiple done channels into one agg_done; it means that if one of a done channel is signaled, the whole agg_done channel is also closed. Yet, we do not know number of done channels during runtime in advanced.

or-channel pattern can do so by using goroutine & recursion .

// return agg_done channel
var or func(channels ... <-chan interface{}) <- chan interface{} 

or = func(channels ...<-chan interface{}) <-chan interface{} {
    // base cases
    switch len(channels) { 
        case 0: return nil
        case 1: return channels[0]
    }

    orDone := make(chan interface{})

    go func() {
        defer close(orDone)

        switch len(channels) {
            case 2: 
                select {
                    case <- channels[0]:
                    case <- channels[1]:
                }
            default:
                select {
                    case <- channels[0]:
                    case <- channels[1]:
                    case <- channels[2]:
                    case <- or(append(channels[3:], orDone)...): // * line
                }

        }

    }
    return orDone
}

line * makes the upper & lower recursive function depends on each other like a tree. The upper injects its own orDone channel into the lower. Then the lower also return its own orDone to the upper.

If any orDone channel closes, the upper & lower both are notified.

4. `tee` channel pattern

This pattern aims to split values coming from a channel into 2 others. So that we can dispatch them into two separate areas of our codebase.

tee := func(
    done <- chan interface{},
    in <- chan interface{},
) (<- chan interface, <- chan interface) {
    out1 := make(chan interface{})
    out2 := make(chan interface{})

    go func() {
        defer close(out1)
        defer close(out2)

        //shadow outer variable
        var out1, out2 = out1, out2
        for val := range orDone(done, in) {
            for i := 0; i < 2; i ++ { //make sure 2 channels received same value
                select {
                case <- done:
                case out1<- val:
                    out1 = nil //stop this channel from being received
                case out2<-val:
                    out2 = nil
                }
            }
        }
    }()
    return out1, out2
}

5. `bridge` channel pattern

Reading values from channel of channels (<-chan <-chan interface{}) can be cumbersome. Hence, this pattern aims to merge all values into 1 channel, so that the consumer jobs is much easier.

bridge := func(
    done <- chan interface{},
    chanStream <- <- interface{},
) <- chan interface{} {
    valStream := make(chan interface{})

    go func() {
        defer close(valStream)

        for {
            var stream <- chan interface{}
            select {
            case maybeStream, ok := <-chanStream
                if ok == false {
                    return
                }
                stream = maybeStream
            case <- done:
                return
            }

            for val := range orDone(done, stream){
                select{
                case valStream <- val:
                case <- done:
                }
            }
        }
    }()
    return valStream
}

References:

Concurrency in Go: Tools and Techniques for Developers - Book by Katherine Cox-Buday

Intro to Concurrency in Golang

Viet Le — Wed, 25 May 2022 00:45:47 +0000

When dealing with conccurency problem, it is harder to reason about when moving down the stack of abstraction (machine, process, thread, hardware components, etc). Most programming languages use thread as its highest level of abstraction. Fortunately, Go build on top of that & introduce Goroutine.

“Share memory by communicating, don’t communicate by sharing memory.” - One of Go’s mottos

Although Golang provides traditional locking mechanism in sync package, its philosophy prefers “share memory by communicating”. Therefore, Golang introduces channel as the medium for Goroutines to communicate with each other.

//goroutine
go func() { 
    // do some work
}()

//channel
dataStream := make(chan interface{})

Fork-join model

Fork-join concurrency model that Go follows

This concurrency model is used in Golang. At anytime; a child Goroutine can be fork to do concurrent work with its parent & then will join back **at some point.

Every Go program has a main Goroutine. The main one can be exit earlier than its children; as a result, a join point is needed to make sure children Goroutine has chance to finish.

Channel

Channel holds the following properties:

Goroutine-safe (Multiple Goroutines can access to shared channel without race condition)
FIFO queue semantics

Channel always return 2 value: 1 is object returned, 1 is status (true means valid object, false means no more values will be sent in this channel)

intStream := make(chan int)
close(intStream)
integer, ok := <- intStream 
fmt.Printf("(%v): %v", ok, integer) // (false): 0

Channel direction

var dataStream <-chan interface{} //read from only channel
var dataStream chan<- interface{} // write to only channel
var dataStream chan interface{} // 2 ways

Channel capacity

Default capacity of a channel is 0 (unbuffered channel). Reading from empty or writing to full channel is blocking.

c := make(chan int,10) //buffered size of 10
c := make(chan int) //unbuffered channel

if a buffered channel is empty and has a receiver, the buffer will be bypassed and the value will be passed directly from the sender to the receiver.

Channel behavior against Goroutine

When a Goroutine read from or write to a channel, various of behaviours might happen depending on channel state.

intStream := make(chan int) // 0 capacity channel

go func() {
    defer close(intStream) 
    for i:=1; i<=5; i++{
      intStream <- i
  }
}()

//range from a channel
for integer := range intStream { // always blocked until the channel is closed
    fmt.Printf("%v ", integer)
}

Below table summarizes all the behaviour:

Operations	Channel state	Result
Read	nil	Block
	Open & not empty	Value
	Open & empyt	Block
	Closed	[default value], `false`
	Write only	Compile error
Write	nil	Block
	Open & full	Block
	Open & not full	Write value
	Closed	`panic`
	Receive only	Compile error
close	nil	`panic`
	Open & not empty	Closes channel. Subsequent reads succeed value until channel is empty, then it reads deafult value.
	Open & empty	Closes channel. Reads produces default value.
	Closed	`panic`
	Receive only	Compile Error

As the behaviour is clomplex, we should have a way to make a robust and scalable program.

Robust & scalable way when working with channel

Here is 1 suggestion way:

At most 1 Goroutine have the ownership of a channel. The channel ownership should be small to be managable.
Channel owner have a write-access (chan←);
While consumer only have read-only view (←chan).

1 Channel owners

Responsibilities:

Init channel
Do write to channel or pass ownership to another goroutine
Close channel
Encapsulate & expose channel as a reader channel

2 Channel consumer

Responsibilities :

Handle when channel is closed
Handle blocking behaviour when reading from channel

chanOwner := func() <-chan int { 
    resultStream := make(chan int, 5) //init
    go func() {
        defer close(resultStream) // close
        for i:=0;i<=5;i++{ 
            resultStream <- i // write
    } }()
    return resultStream // read channel returned
}

resultStream := chanOwner()
for result := range resultStream {
  fmt.Printf("Received: %d\n", result)
}
fmt.Println("Done receiving!")

Refereneces:

Concurrency in Go: Tools and Techniques for Developers - Book by Katherine Cox-Buday

The minimum every developer must know about CORS

Viet Le — Wed, 18 May 2022 02:47:52 +0000

What is CORS?

CORS stands for Cross-Origin Resource Sharing.
CORS is HTTP-header based mechanism set by server to inform client side about allowed origins (<scheme>://<hostname>:<port>) other than its own. It also indicates method and headers which the server is willing to support (example included below).
Most of client browsers enforce CORS whenever a cross-origin request is made. A request is cross-origin if it calls to outside origins, which are different from the one served the first resource.

CORS behaviour will be different between simple & “pre-flighted” requests. Let’s see the detail below.

Simple requests

Refer here for full defition of simple request. For example, a GET request with no header is a simple request.
A simple request is sent directly to server. Let’s see how it works in the example below:

Source: MDN web docs
- Request 1: Client browser first load a web document from domain-a.com . The main request defines its origin as domain-a.com. This origin is then specified in the request header of subsequent requests.
```
Origin: <origin>
```
- Request 2: Client browser then send request to GET resource from domain-a.com. As comming from the same origin, the requested resource is fetched & rendered by browser.
- Request 3: similar to request 2, but the request now is sent to domain-b.com , which is a different origin.
  - The resource will be successfully fetched, but ...
  - It might be rendered by the browser only if in the response header, the allowed origin == domain-a.com (the request origin) or when it is a wildcard (*) meaning permit all origin.
```
Access-Control-Allow-Origin: <origin> | *
```

“Pre-flighted” requests

Any requests that are not simple is “pre-flighted” one.
Unlike simple request, the browser will send a “preflight” request (OPTION method) to see if the actual one ( ”pre-flighted” one ) is allowed by the server.

Source: MDN web docs

A preflight request will include the following headers:
Server responses with the following headers if it supports:
Then, the browser will compare value in the response header against corresponding info of the actual request. If all is allowed, the actual request is sent; otherwise, not.
The preflight request can also be cached in client side with the time-to-live indicated in Access-Control-Max-Age response header

Final note

CORS is server-side security configurations that clients may enforce it.

Most browsers do (to avoid attack like CSRF).
Some dev tools do not (like Postman).

About me

Viet Le — Fri, 06 May 2022 06:52:19 +0000

Who am I?

Hi there 👋 . I am Viet-Minh Le (@vietmle_).

🎓 Information Engineering & Media ‘22 @ NTU
💼 Backend Engineer @ ShopeeSG
🧑🏻‍💻 Tech stacks: .py, .go, .js , and some more …

Why I start this blog?

As a non-CS degree person, I find it overwhelmed when self-studying to become a software engineer. I was lucky enough to be guided by my senior, since then my studying process is much easier.

As a result, I start this blog to share my coding journey and hope some of my articles help you in some ways as well.

Moreover, through this blog, I also hope that I can connect with and learn from new like-minded friends like you.

Follow me (@vietmle_) on Twitter to get update whenever my new article is out!