A month ago, I was working on a Golang project. This project is related to some authorization data. To make it short, this project must be deployed in multi-region because of the needs of our services.

We use a global database with replicated database for all regions. In our case, for example, our application is deployed in us-west-2 and ap-southeast-1 region. If drawn into a diagram, it will look like this:

So there is nothing wrong with this. But the problem is, when handling the connection separation, I take time to understand how to do this in Golang with ease. I searched for a library that can help with this, and I found one, DBResolver from Gorm, but the problem is that we’re not using Gorm. With some tradeoffs, I decided to write my library that will utilize the connection separations for the Database in Golang.

Introducing Golang dbresolver for Built-In Golang sql.DB

Moving from the abovementioned problem, I created my own Golang library to handle database connections.

• https://github.com/bxcodec/dbresolver

Use case 1: separated RW and RO database connection

Imagine you’re building an application (e.g., a media platform like Medium.com) with heavy read operations (query) to the database. Let’s say your database limit connection is only 100, but you have a lot of concurrent users coming in and eventually using all the maximum connections to the database. This will impact performance and user experience.

How to handle this easily is by replicating the DB and separating between the “Write” and “Read” databases. In this case, we will define one Primary (master/leader) database and create other replicas depending on needs (maybe 2–3 replicas for read-only).

So to summarize:

• You have your application deployed
• Your application is heavy on reading operations
• Your DBs replicated to multiple replicas for faster queries
• You separate the connections for optimized query

usecase#1 dbresolver

Use case 2: cross-region database

This is a similar use case to use case#1. The difference is that in use case #1, your application is only deployed and running in 1 region. In this use case, you need to serve a multi-region application but still want to make it consistent across regions.

Let’s say an authorization and authentication service may be an example for this use case. Since it is heavy on reading operations, e.g., Select User info, get user permission list, get user role, etc., and since it’s an authorization system, it should be available globally. So if we block some users’ access, it should be blocked in every region. That’s why we need to ensure the application is deployed across all regions.

• Your application deployed to multi regions.
• You have your Databases configured globally.

usecase#2 dbresolver

Using dbresolver

Based on the use cases I mentioned above, building it with the builtin *sql.DB will take time. Worry not. I created this library to save you time when facing similar use cases.

Here’s the main features:

• Clear differentiation between Primary and Replicas.
  With this library, you can define your primary and replicas explicitly without worrying about wrong configurations.
• ReadWrite to Primary, ReadOnly to Replicas
  All write operations will automatically go to the Primary and read operations to replicas (currently only support round-robin if has using more than one replicas).
  So whenever you call these functions (Exec, ExecContext, Begin, BeginTx) in your application, it will automatically be using the primary database. But if you use these functions (Query, QueryContext, QueryRow, QueryRowContext), it will automatically be using the replicas database.

example

Example With Use Case 1: Multi Readers in One Region

To give an example of how to use it with a multi-reader database, here’s the code:

It’s pretty clear here — we only need to define all of our readers’ connections. And initialize the library. After that, we can use it for our database operation in our application.

Example With Use Case 2: Multi-Region Application

And this is an example of how to use it with multi-region applications.

This example is quite different. With use case #1, we need to declare all our connection strings explicitly. Here, you only need to declare one reader, but you need to do a kind of branching logic, like if region is 'us-west-2' then use the 'us-west-2 environments

The rest of it will be handled by the library.

GitHub Repository

Sounds awesome? Exactly, now you can save your time more on your business logic. Let this library handle your connection database.

Find the GitHub repo here:

• https://github.com/bxcodec/dbresolver

And feel free to raise an issue or PR if you have a better idea for improving this tiny yet useful library.

Introducing Go Image Slicer: The Comprehensive Go Package for Image Slicing and Joining, Filling the Gap in Go’s Image Processing Landscape

I was tasked with building a puzzle game in Go, but I struggled to find a reliable library or article on how to slice images. Eventually, I had to settle for using Python’s image-slicer and build a Python microservice — Game-Engine — instead. However, after gaining a deep understanding of how image-slicer worked in Python, I decided to fill the gap in Go and create my own image-slicing library. This led me to create Go Image Slicer, a powerful and easy-to-use package for slicing and joining images in Go.

This tutorial will assume you have some basic Go programming knowledge (e.g. Syntax and Fundamentals Concept). If you don’t know what Go is or how to write basic Go programming, I recommend you to start learning from here first ( https://go.dev/tour/).

1. Install Go 1.19+ (Learn how to install Go here https://go.dev/doc/install)

1. Create Project Directory

mkdir go-slice-images

2. Init the Go Modules

go mod init example/go-slice-images

go get github.com/golangFame/imageslicer

2. Lets write a program to slice an image and save the tiles to a directory

slice images into 2*2 grid and save ’em in the “sliced_tiles” directory

3. Run the program

go run slice_image_2*2.go

1. https://github.com/golangFame/imageslicer/tree/main/examples/basic
2. https://gist.github.com/Nasfame/3dd713bbc4b36c64590f39d3dc58904b

Join(tiles,grid) (img image.Image, err error)

2. Try out other easily available functions such as reading image for base64, urls and local paths.

GetImageFromBase64(base64str) (img image.Image, err error)
GetImageFromUrl(imgUrl) (img image.Image)
GetImageFromPath(imgLocalPath) (img image.Image, err error)

3. Checkout the tests integrated to the code repo.

4. Checkout Go Workspaces

Originally published at https://medium.com on May 12, 2023.

I have chosen not to pursue opportunities with the following companies !!

• XL Dynamics
• Nuvento
• Fynd
• Cloud Collab
• Pyor
• Hypertest
• ZopSmart
• Bzinga
• Zepto

I have either worked with these companies in the past and have decided to explore new work environments, or I have interviewed with them and had negative experiences. Additionally, I have researched their work culture and have had conversations with current and former employees, and based on that information, I have determined that these companies would not be a good fit for me. It’s important to me to work for a company whose values and culture align with my own, and unfortunately, I do not see that alignment with these particular companies.

While I really appreciate their interest in my skills and experience, I think that these companies are not the right fit for me at this time. I kindly request that recruiters from these companies do not contact me in the future. Thank you for your understanding.

P.S — I want to reiterate that my sole intention in sharing this list of companies is to save everyone’s time. I believe that it’s important to be transparent about my preferences and avoid wasting anyone’s time, including my own and that of recruiters from these companies. Thank you for your understanding.

Those interesting in connecting me — Contact Me