DEV Community: ynwd

Horizontal Scaling: Solving One Problem, Creating Another

ynwd — Wed, 12 Aug 2026 02:18:05 +0000

When learning system design, we are almost always fed the exact same doctrine: start with one API + one Database, then as traffic increases, add a Load Balancer, Redis, a Separate Database Server, and eventually Read Replicas.

The problem is that this standard pattern is built on a single assumption: every user must crowd into the same shared database. However, if your application's data characteristics allow it to be segregated per user from day one, blindly following this pattern becomes a complexity trap that makes your system increasingly fragile.

The Sin of Mainstream Architecture: Compounding New Problems

In conventional architecture, all users share the same database tables. As server load increases, a developer's first reflex is usually to add more infrastructure layers:

[User] 
  └─► [Load Balancer]
        ├─► [API Instance 1] ──┐
        │                      ├─► [Redis Cache]
        └─► [API Instance 2] ──┴─► [DB Server (Postgres)]

While the initial intent is to solve scaling challenges, the execution creates a dramatic contradiction:

1. Seeking Fault Tolerance, but Adding a Single Point of Failure

To distribute traffic, we introduce a Load Balancer and spin up additional API instances. However, because user requests now bounce between instances, their session state is lost.

The Solution?
We are forced to introduce Redis for centralized session storage.

The Absurd Result: We added a Load Balancer to make the system fault-tolerant, but now, if Redis crashes, the entire application goes down.

2. Seeking Easy Scaling, but Paying with Complex Bugs

In theory, spinning up another API server is just a click of a button. However, once a single business transaction touches multiple servers simultaneously, standard database transactions (BEGIN...COMMIT) no longer work.

We are forced to implement complex patterns like Two-Phase Commit or the Saga Pattern. We chose horizontal scaling in pursuit of simplicity, but ended up trapped in race conditions and data inconsistency issues that are notoriously hard to debug in production.

A Radical Solution: The File-per-User Architecture

Instead of forcing all data into one giant database, this approach offers a remarkably simple concept: give every user their own separate SQLite file.

/data
  ├── user_01.db
  ├── user_02.db
  └── global_index.db  <-- For public metadata/aggregates only

So, what happens when the application needs public features like a feed, global search, or cross-user data aggregation?

The Answer: Separate the read path.

Private source data remains safely stored in each user's individual file. Whenever a user publishes something, the application simply writes a lightweight metadata entry (write-on-publish) to a dedicated aggregate database. If this aggregate database becomes corrupted, its data can easily be re-indexed from the users' primary files.

By eliminating a separate database server and embedding the SQLite engine directly inside the application process, system mechanics shift naturally:

Data Leaks Become Structurally Impossible: In a shared database, a single bug forgetting a WHERE user_id = ? clause can leak data between users. In this approach, the application connection strictly opens the target user's file. The risk of data leakage is eliminated not by developer vigilance, but by physical file boundaries.
Radically Simple Backups: You no longer need to execute gigabyte-sized database dumps or manage complex log replication pipelines. To back up a user's data, you simply stream or copy their single .db file to Object Storage (e.g., using Litestream).
Zero Network Latency: Because the database engine runs inside the application process itself, every query is processed directly in memory and local disk. Network calls from the API server to the DB server—which typically consume milliseconds—vanish entirely.

The Rationality of Vertical Scaling: Why It Is More Than Enough

A reasonable question arises: "If the database lives as local files, how do we handle traffic spikes? We can't just slap a Load Balancer in front of it."

The Answer: Use Vertical Scaling (scale up the machine's resources).

In the modern cloud era, scaling CPU and RAM on a single server is often overlooked because it is deemed less fashionable than running dozens of small nodes. Yet, the logic behind vertical scaling is stronger than ever: a single modern machine can handle tens of thousands of requests per second provided its performance isn't bogged down by database network latency and distributed state synchronization.

The physical capacity of a single server today has reached almost absurd levels. On Google Cloud Platform (GCP), a standard Virtual Machine can offer up to 224 vCPUs. In Memory-Optimized categories (such as the M or X4 series), limits reach up to 1,920 vCPUs and a massive 32 Terabytes (32,768 GB) of RAM on a single machine. These specs prove that the physical ceiling of a single server far exceeds the compute needs of 99.9% of web applications on the market.

Based on this reality, the architecture divides infrastructure responsibilities pragmatically:

Compute (CPU/RAM): Scaled vertically. You leverage the capacity of a single machine to execute all application logic and embedded database operations in one place without network overhead.
Storage (Disk): Scaled horizontally without limits. Storage capacity is not constrained by the machine itself; you can attach new block storage volumes (e.g., up to hundreds of Terabytes) instantly with zero downtime.

Ultimately, instead of stressing over a complex architecture built for hypothetical hyper-scale traffic, you choose a simple, rational system: one application, one server, and zero network overhead.

When to Use This Pattern?

Highly Recommended If:

Most user activity takes place within their own isolated data context (SaaS, E-commerce, Social Platforms, Productivity Tools).
You prioritize operational simplicity and low maintenance overhead with a small engineering team.
You want to ship and deploy applications rapidly without managing server clusters.

Avoid If:

Your application is dominated by ad-hoc, cross-user queries with unpredictable read patterns—making it difficult to structure a lightweight aggregate database.
The total traffic and compute load of a single application has been empirically proven to exceed the physical limits of the largest single server available on the market.

Conclusion

Load balancers, Redis, and separate database clusters are not badges of system maturity—more often than not, they are technical debt stemming from poor architectural choices made early on.

If your user data can be isolated per file, stop bundling it into one giant shared database. Separate the data, offload global search to a lightweight aggregate index, drop the separate database server, and enjoy a system that is significantly faster, more stable, and easier to maintain.

Q&A: Addressing Operational and Security Concerns

"A single server is a Single Point of Failure (SPOF) & hard to Failover!"

That mindset belongs to an era when SQLite was viewed merely as a passive local disk file. The modern SQLite ecosystem has solved this:

For Disaster Recovery (DR): Use Litestream. It performs byte-level streaming replication in real-time to Object Storage (S3/Cloudflare R2). If the primary server is completely destroyed, you can restore the latest state to a fresh server in minutes.
For Automatic Failover (High Availability): Use LiteFS. LiteFS creates a multi-node SQLite cluster where read requests are handled locally and write requests are automatically forwarded to the primary node. (To be intellectually honest: adopting LiteFS means re-introducing a degree of distributed system complexity that was initially avoided. However, this aligns with the core philosophy: add infrastructure complexity only when HA requirements are genuinely proven, not on day one).

"How do you handle Zero-Downtime Deployments?"

You do not need Kubernetes just to achieve zero-downtime deployments! There are two straightforward approaches:

At the Server Level: Use a reverse proxy like Caddy, Nginx, or Envoy to execute hot-reloads. Alternatively, leverage Linux's systemd Socket Activation—the OS buffers incoming requests for a few milliseconds at the kernel level while the application process switches over, resulting in zero dropped requests.
At the Edge Level: Utilize Cloudflare (via Cloudflare Tunnel). You can re-route traffic to a new port or binary version via API, get free DDoS protection, and serve automatic maintenance pages if the server ever requires a full reboot.

"Complexity is just shifted to the Application Layer!"

That is actually a net positive!

Application-layer complexity can be tested automatically using standard unit and integration tests on your local machine (localhost). In contrast, distributed infrastructure complexity (such as split-brain scenarios in a DB cluster or subtle Redis race conditions) manifests as ghost bugs that are nearly impossible to reproduce locally and only surface when production breaks.

Would you rather deal with complex test suites or be paged at 3 AM because production is down?

"What about Analytics / Data Warehouse Queries?"

No one should run heavy analytical queries directly against production SQLite files. Even in conventional distributed architectures, best practices strictly dictate never pointing OLAP/analytics queries at a production OLTP database.

Because all .db files are backed up automatically to S3 via Litestream, the Data team can point query engines like DuckDB or ClickHouse directly at those S3 snapshots. DuckDB can query thousands of SQLite files in parallel with exceptional speed, leaving the production database completely unburdened.

"Hard to pass Compliance Audits (GDPR/ISO) & handle Backups!"

The File-per-User architecture actually simplifies data isolation and compliance governance:

Right to be Forgotten (GDPR Erasure): In a shared database, deleting a user's data requires cascading DELETE statements across dozens of tables, running the risk of table locks or orphaned records. In this approach, a user's private data is completely isolated. You simply delete their user.db file and clear their entry in the aggregate database. (Ensure you configure proper **Lifecycle / Retention Policies* on your Object Storage where Litestream streams backups, so historical copies are permanently purged according to regulatory windows).*
Data Portability: If a user requests a full export of their personal data, you hand them a copy of their single .db file—no complex export scripts required.

"Career-Safety Principle (Nobody gets fired for buying IBM)"

This is the real underlying reason: Fear.

Many choose complex architectures not because the application requires it, but out of fear of blame if things break, or simply to polish their resume with industry buzzwords (Resume-Driven Development).

The mark of a mature Engineering Leader is having the courage to choose the simplest possible architecture that solves the business problem while incurring the lowest possible distributed infrastructure tax.

I Built a Web Framework That Only Works With AI

ynwd — Fri, 17 Jul 2026 10:22:38 +0000

Stop fixing boilerplate. Let AI do the boring parts — scaffold, code, review, ship.

Here's the problem nobody talks about: most AI coding assistants are wasted on repos that weren't designed for them.

You ask Copilot to "add a billing feature" and it generates files in the wrong places, imports from the wrong modules, or writes code that doesn't match your project's conventions. You spend more time fixing the AI's output than you would writing it yourself.

I got tired of this. So I built something different.

Meet Flow

Flow is a modular monolith (Go + React) where every convention exists for the AI, not for you.

┌──────────────────────────────────────────────┐
│ "buat fitur billing" →                        │
│   @analyst asks 2 questions →                 │
│   you approve →                               │
│   AI scaffolds, codes & reviews →             │
│   you ship.                                   │
└──────────────────────────────────────────────┘

One command from zero to running:

git clone <repo> && cd flow
.github/skills/init-core-project/scripts/init-core.sh
go run .    # → localhost:3000

The Problem: Frameworks Were Built for Humans

Traditional frameworks assume a person writes the code. The folder structure, the conventions, the design patterns — they all make sense to a human brain.

But AI doesn't think like us. It hallucinates file paths. It imports from the wrong module. It guesses conventions instead of following them.

Flow flips this: everything is designed so an AI can't get it wrong.

How It Works

1. One Feature = One Folder

No more "where do I put the handler?" The AI can't scatter your code across the tree because both your Go backend and React frontend live in the same folder.

modules/billing/
├── handler.go        # HTTP handlers
├── service.go        # Business logic
├── repository.go     # Data access
├── model.go          # Types
├── module.go         # Self-registration
├── billing.tsx       # React component
├── api.ts            # Fetch client
└── components/       # Local React components

2. Self-Registration Pattern

Modules register themselves via Go's init() function. No manual wiring, no import management. The AI just needs to create the folder and the rest happens automatically.

3. Skills — Not Hallucinations

Instead of letting the AI guess how to scaffold a module, I gave it battle-tested shell scripts:

.github/skills/new-feature-module/scripts/scaffold.sh billing

This creates a full CRUD module — Go backend, React frontend, tests, auto-registered — in one command. The AI doesn't guess. It executes.

4. Custom Agent Modes

Flow ships with preset GitHub Copilot agent modes:

Agent	What it does
`@implementer`	Has write access — implements features, fixes bugs
`@reviewer`	Read-only — checks architecture and module boundaries
`@analyst`	Clarifies requirements and writes specs
`@planner`	Produces user stories for large features

Workflow:

You → @analyst writes spec → You approve → @implementer codes → @reviewer checks → Ship

A Real Use Case: Building a Blog Feature

Let's walk through what it looks like to build something real — a simple blog feature.

Step 1: Init the project (once)

.github/skills/init-core-project/scripts/init-core.sh

This creates the entire core structure — router, middlewares, templates, static files, Tailwind CSS — from templates. It runs go mod tidy, npm install, npm run build:css, and go build ./... automatically.

Step 2: Scaffold the blog module

.github/skills/new-feature-module/scripts/scaffold.sh blog --ssr

The --ssr flag enables server-side rendering (SEO-friendly). This creates:

modules/blog/
├── handler.go         # Page + API handlers
├── service.go         # Blog logic
├── repository.go      # In-memory store
├── model.go           # Post struct
├── module.go          # Routes registration
├── router.go          # Route definitions
├── templates/         # HTML templates (SSR)
├── blog.tsx           # React component
├── api.ts             # Fetch client
├── package.json       # Frontend deps
├── esbuild.mjs        # Build config
└── handler_test.go, service_test.go, api.test.ts, blog.test.tsx

Step 3: Have the AI implement it

In VS Code, open the Copilot chat and type:

@implementer implement the blog feature per the spec at .github/specs/blog.md

The @implementer agent will:

Read the spec
Fill in the handler, service, and repository with business logic
Add tests
Run go build ./... && go test ./...
Build the frontend bundle

Step 4: Review

@reviewer review the blog module against spec

The @reviewer agent reads the code, checks module boundaries, and reports any issues. If it finds problems, it calls @implementer to fix them automatically.

Step 5: Ship

npm run build -w modules/blog
go run .    # → localhost:3000/blog

What You Get Out of the Box

Feature	How
Project init	`init-core.sh` — single command from clone to running
Module scaffolding	`scaffold.sh` — full CRUD with Go + React + tests
Code generation	4 agent modes + 3 prompt templates
Code review	`@reviewer` checks architecture automatically
State tracking	`.core-state.json` prevents overwriting existing files
Styling	Tailwind CSS v4, built via PostCSS
Database	In-memory (swap to SQLite/Postgres when ready)
Auth	Bearer token middleware (extensible)

Why Devs Like It

"Took me 10 minutes to go from first commit to a working API. The AI did all the boring parts."
"Finally — a framework that doesn't fight me when I use Copilot."
"The scaffold script alone saves me 30 minutes per module."

Try It Yourself

git clone https://github.com/ynwd/flow
cd flow
.github/skills/init-core-project/scripts/init-core.sh
go run .

Then open VS Code, press Cmd+I, and tell Copilot:

@implementer add a blog module with SSR

It just works.

Flow is open source. Built with Go 1.24, React 18, TypeScript 5, Tailwind CSS v4, and a lot of coffee.

Making the Filing Cabinet Enterprise-Ready: Tricks to Scale with SQLite

ynwd — Sun, 17 May 2026 02:34:55 +0000

In my previous article, we talked about why big databases (like Postgres or MySQL) act like a remote, slow mega-warehouse. Meanwhile, SQLite acts like a fast filing cabinet right under your desk.

But a common question arises: "Can a simple filing cabinet handle a serious, growing enterprise business?"

The answer is yes. You don't need a massive warehouse just because your business is growing. You just need to know how to organize your filing cabinet.

Here are the simple, practical tricks to make SQLite ready for enterprise apps.

1. Turn on WAL Mode (The "Double Desk" Trick)

By default, SQLite works like a cautious clerk: if someone is writing down a new file, nobody else can read the existing files until the writing is finished. This can cause a small delay.

To fix this, you must turn on WAL (Write-Ahead Log) mode.

Think of WAL mode as having two desks.

Desk A (The Archive): People can read files from here anytime without waiting.
Desk B (The Scratchpad): New data is written here first in the background.

Every once in a while, the system automatically moves data from Desk B to Desk A. With WAL mode, readers never block writers, and writers never block readers. It makes concurrency instant.

How to do it: Just run this simple command when your app connects to SQLite:
PRAGMA journal_mode=WAL;

2. Optimize the Speed (The "Hyper-Drive" Settings)

To make your filing cabinet even faster, you can give SQLite a few extra instructions (called PRAGMAs) when your application starts:

PRAGMA synchronous = NORMAL; Instead of stopping and checking the hard drive after every single letter is written, SQLite trusts the computer's memory cache. It is safe, and it makes writing data significantly faster.
PRAGMA cache_size = -64000; This tells SQLite to keep more data inside the RAM (around 64MB). Reading data from RAM is like instantly remembering a phone number instead of looking it up in a book.
PRAGMA busy_timeout = 5000; If two actions happen at the exact same fraction of a second, this tells the second action to wait patiently for up to 5 seconds instead of crashing with an error.

3. The Multi-Tenant Strategy: One Tenant, One File

In a big enterprise application, you usually have many customers (tenants). The old corporate way is to dump millions of rows from all customers into one giant database table. This makes queries slow and dangerous if data leaks between clients.

The enterprise SQLite way is beautiful: Give every customer their own separate SQLite file.

Safer: Customer A can never accidentally see Customer B's data because they are literally in different files (tenant_A.db, tenant_B.db).
Faster: Backing up data is as simple as copying a single file for that specific customer.
Infinite Scaling: You don't need a bigger server. If you get 10,000 new customers, you just create 10,000 small files. You can even distribute these files across cheap, simple servers.

4. Automatic Backups to the Cloud

People worry: "What if the server crashes and I lose my SQLite file?"

In an enterprise setup, you use a tool like Litestream or LiteFS. These are tiny, invisible background helpers designed for SQLite.

Every time a user changes a single piece of data in your SQLite file, Litestream instantly streams that tiny change to secure, cheap cloud storage (like Amazon S3 or Google Cloud Storage). If your server burns down, you can restore your database up to the last millisecond.

5. Keep the Frontend as the Orchestrator

To keep your backend fast and lightweight, let your frontend (the user interface) handle the complex user flows. The backend should focus on doing one thing perfectly: reading and writing data to the local SQLite file as quickly as possible.

By keeping the business logic modular and letting the frontend drive the orchestration, your SQLite database stays clean, unburdened, and lightning-fast.

Conclusion

Enterprise-ready doesn't mean "complex." It means reliable, secure, and fast.

By turning on WAL mode, tuning the cache, using a "One Tenant, One File" strategy, and adding automated cloud streaming, SQLite can easily power a highly profitable SaaS platform.

Stop paying for expensive database clusters that sleep most of the time. Optimize your desk drawer, and watch your application fly.

The Secret of the Small Database: Why "Big" Technology Often Slows You Down

ynwd — Fri, 15 May 2026 01:28:06 +0000

Imagine you are running a business. You need to save and retrieve files every day. You have two choices:

The Remote Mega-Warehouse: A massive, high-security building located 10 miles away. Every time you want to save a single piece of paper, you have to call a courier, wait for them to drive there, pass through three security checkpoints, wait for a clerk to find an empty shelf, and then get a confirmation call back.
The Desktop Filing Cabinet: A small, incredibly fast drawer right under your desk. You open it, drop the paper in, and close it. Total time: half a second.

In the world of technology, Oracle, Microsoft SQL Server, MySQL, and PostgreSQL are the Mega-Warehouses. SQLite is the filing cabinet.

The "Big Four" and the Hidden Tax

When companies choose big names like Oracle or MySQL, they think they are buying "power." While these systems are very capable, they come with a "Hidden Tax" that most people don't notice until their app starts feeling slow.

1. The "Distance Tax" (Networking)

Big databases usually live on a different computer (server) than your app. Every time your app wants to save data, it has to send a message over a network "wire." Even at the speed of light, this takes time.

Big Databases: Every request is a round-trip journey.
SQLite: It lives inside your app. There is no journey.

2. The "Bureaucracy Tax" (Locking & Security)

Because big databases are designed for thousands of people to use at once, they have massive "red tape." Before saving data, the database checks:

"Who are you?" (Authentication)
"Do you have permission?" (Authorization)
"Is someone else touching this specific row?" (Locking)

While this sounds smart, it creates a massive line-up. If 1,000 people try to save data at the same time, the "Mega-Warehouse" gets a traffic jam at the front gate.

3. The "Maintenance Tax" (Cost)

Systems like Oracle or MS SQL Server are so complex that you need to hire highly-paid specialists (DBAs) just to keep them running. They require expensive monthly subscriptions and heavy hardware.

SQLite: The Invisible Champion

Most people think SQLite is a "lite" or "toy" version of a database. This is a mistake. SQLite is likely the most used piece of software on Earth. It is inside your iPhone, your Android, your car's GPS, and even inside the airplanes you fly in.

Why is it so fast?

No Paperwork: It doesn't ask for a password every time you save a word. It trusts the app it's sitting in.
No Travel: It’s a file on your hard drive. Reading it is as fast as opening a photo.
Extreme Reliability: It is designed to never crash, even if the power goes out suddenly.

The Common Trap: "We Might Need to Scale"

The biggest reason developers choose the "Mega-Warehouse" (MySQL/Postgres) is a fear of the future. They think, "What if we have millions of users one day?"

So, they build a complex, expensive system on Day 1. But here is the irony: The complexity itself makes the system slow. By trying to prepare for a million users, they make the experience worse for their first 1,000 users.

A Better Way: The "Personal Cabinet" Strategy
Instead of putting 1,000,000 users into one giant, slow warehouse, smart architects are now giving each user (or group of users) their own "Personal Filing Cabinet" (a separate SQLite file).

Result: 1,000 users can all save data at the exact same time without ever waiting in line. No traffic jams. No "Remote Warehouse" fees.

Summary: Which one do you actually need?

Feature	The Big Guys (Oracle, MySQL, etc.)	The Simple Guy (SQLite)
Speed	Slow (due to network & red tape).	Instant (it's right there).
Cost	Expensive (Servers + Staff).	Free (Zero maintenance).
Setup	Hard (Needs a professional).	Easy (Just works).
Best For	Many different servers sharing data.	Apps that need to be fast and cheap.

The Bottom Line:
Don't be fooled by big names and expensive price tags. In technology, "complex" doesn't mean "better." Sometimes, the fastest way to get the job done is to stop calling the warehouse and just open your own desk drawer.

Why Use Google Cloud Run for Your MVP?

ynwd — Sat, 25 Oct 2025 06:58:01 +0000

🧭 TL;DR

Cloud Run = deploy fast, scale smart, pay only when used.

It’s the perfect environment to validate your MVP idea without committing to complex infrastructure or large bills.

Using Google Cloud Run for your MVP (Minimum Viable Product) is a smart move — especially if you want speed, scalability, and low operational overhead. Here’s why it’s often the best fit 👇

🚀 1. Fast Deployment — Focus on the Product, Not Infrastructure

Deploy a containerized web app or API with one command (gcloud run deploy).
No need to manage servers, VMs, or Kubernetes clusters.
Perfect for testing ideas and iterating quickly.

💰 2. Pay Only for What You Use

Cloud Run is fully serverless — it scales down to zero when idle.
You pay only when requests are being handled (per CPU/Memory/Request).
Ideal for MVPs with unpredictable or low traffic at the start.

⚙️ 3. Scales Automatically

If your MVP suddenly gets traction, Cloud Run automatically scales up to handle thousands of requests.
When traffic drops, it scales back down to zero — no manual tuning.

🧩 4. Easy Integration with Other GCP Services

Works seamlessly with:
- Cloud SQL (for databases)
- Cloud Storage
- Pub/Sub, Firestore, Secret Manager
Great for evolving an MVP into a production system later.

🧱 5. Language & Framework Agnostic

Use Node.js, Go, Python, Rust, Java, or anything that runs in a container.
Perfect if your team uses diverse stacks or microservices.

🔐 6. Built-in Security

HTTPS by default with automatic TLS certificates.
IAM-based access control.
Private service connections for secure internal APIs.

🧪 7. Smooth Dev→Prod Path

Start with local Docker builds and deploy the same image to Cloud Run — no surprises.
Great compatibility with GitHub Actions or Cloud Build for CI/CD.

⚡ Bonus: Example MVP Use Cases

MVP Type	Cloud Run Advantage
API backend	Auto-scale and low idle cost
Web dashboard	Easy HTTPS and zero-maintenance
Background jobs	Event-driven with Pub/Sub triggers
AI inference microservice	Scales per-request, fast cold starts

source:
https://chatgpt.com/share/68fc51f5-94c0-800d-a18b-f0c43d5286a3

Build React SSR Page in Seconds Powered by Deno and TypeScript

ynwd — Tue, 01 Aug 2023 06:00:52 +0000

Supercharge your SSR workflow: Harness the power of Fastro, Deno, and TypeScript to build React SSR pages in mere seconds.

First, make sure you have Deno installed. See the deno manual for details.

Then, create a folder for your project and enter to it.

mkdir my-project && cd my-project

Generate default project from command line.

deno run -A -r https://fastro.deno.dev

The above command will generate default folders and files that you can use for the initial project.

Now let's run the application

deno task start

If there is no problem, you will see this message on the terminal

Listening on http://localhost:8000

Open that link on your browser or hit them via curl

curl http://localhost:8000

You can find more detailed instructions in the fastro manual page.

Design pattern in golang: builder

ynwd — Sun, 14 Nov 2021 10:25:42 +0000

Builder pattern dipakai untuk membuat sebuah instance dari sebuah struct -- beserta dengan semua propertinya.

Perhatikan struct berikut:

package main

type User struct {
    name        string
    email       string
    address     string
    dateOfBirth DateOfBirth
}

package main

type DateOfBirth struct {
    year  int
    month int
    day   int
}

Implementasi pattern

package main

import (
    "fmt"
    "strconv"
    "strings"
)

func newUserBuilder() *User {
    return &User{}
}

func (u *User) Build() (User, error) {
    return User{
        name:        u.name,
        email:       u.email,
        address:     u.address,
        dateOfBirth: u.dateOfBirth,
    }, nil
}

func (u *User) SetName(name string) {
    u.name = name
}

func (u *User) SetEmail(email string) {
    u.email = email
}

func (u *User) SetAddress(address string) {
    u.address = address
}

func (u *User) SetDateOfBirth(dob string) {
    splitted := strings.Split(dob, "/")

    day, err := strconv.Atoi(splitted[0])
    if err != nil {
        u.dateOfBirth = DateOfBirth{}
    }

    month, err := strconv.Atoi(splitted[1])
    if err != nil {
        u.dateOfBirth = DateOfBirth{}
    }

    year, err := strconv.Atoi(splitted[2])
    if err != nil {
        u.dateOfBirth = DateOfBirth{}
    }

    u.dateOfBirth = DateOfBirth{day, month, year}
}

Bahkan, kalau mau, kamu dapat menambahkan validasi pada setiap variabel yang akan menjadi input -- sebelum ia dipakai oleh setiap properti dari sebuah struct.

Cara penggunaan

package main

func main() {
    builder := newUserBuilder()
    builder.SetName("agus")
    builder.SetAddress("cirebon")
    builder.SetEmail("agus@email.com")
    builder.SetDateOfBirth("01/01/2020")
    user, err := builder.Build()
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(user)
}

Kesimpulan

Dengan builder pattern kita dapat membuat instance dari sebuah struct dan menambahkan validasi pada variabel-variabel yang akan menjadi input-nya.

Source code

https://play.golang.org/p/7nBzfPFT8ix

Measuring mutex, channel and waitGroup performance

ynwd — Sat, 13 Nov 2021 06:45:06 +0000

function	concurrency
getText	no
getTextWithChannel	yes
getTextWithWaitGroup	yes
getTextWithMutex	yes

Source code:

package main

import (
    "fmt"
    "sync"
    "time"
)

func getText() string {
    i := "hi"

    func() {
        i = "hello"
    }()

    return i
}

func getTextWithWaitGroup() string {
    t := "hi"
    var waitgroup sync.WaitGroup
    waitgroup.Add(1)

    go func() {
        t = "hello"
        waitgroup.Done()
    }()

    waitgroup.Wait()
    return t

}

func getTextWithChannel() string {
    t := "hi"
    done := make(chan bool)

    go func() {
        t = "hello"
        done <- true
    }()

    <-done
    return t
}

func getTextWithMutex() string {
    i := text{txt: "hi"}
    go func() {
        i.Set("hello")
    }()
    return i.Get()
}

type text struct {
    txt   string
    mutex sync.Mutex
}

func (t *text) Set(txt string) {
    t.mutex.Lock()
    defer t.mutex.Unlock()
    t.txt = txt
}

func (t *text) Get() string {
    t.mutex.Lock()
    defer t.mutex.Unlock()
    return t.txt
}

Benchmark test:

package main

import "testing"

func BenchmarkGetText(b *testing.B) {
    for i := 0; i < b.N; i++ {
        getText()
    }
}

func BenchmarkGetTextWithChannel(b *testing.B) {
    for i := 0; i < b.N; i++ {
        getTextWithChannel()
    }
}

func BenchmarkGetTextWithWaitGroup(b *testing.B) {
    for i := 0; i < b.N; i++ {
        getTextWithWaitGroup()
    }
}

func BenchmarkGetTextWithMutex(b *testing.B) {
    for i := 0; i < b.N; i++ {
        getTextWithMutex()
    }
}

Result:

Running tool: /usr/local/go/bin/go test -benchmem -run=^$ -coverprofile=/var/folders/43/sjvtz21j0kq56_7vc9nchb400000gq/T/vscode-goeIm86z/go-code-cover -bench . github.com/ynwd/monorepo/Documents/apps/cms/cmd

goos: darwin
goarch: amd64
pkg: github.com/ynwd/monorepo/Documents/apps/cms/cmd
cpu: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
BenchmarkGetText-8                  1000000000           0.5197 ns/op          0 B/op          0 allocs/op
BenchmarkGetTextWithChannel-8        1826163           644.4 ns/op       136 B/op          3 allocs/op
BenchmarkGetTextWithWaitGroup-8      1780219           670.9 ns/op        56 B/op          3 allocs/op
BenchmarkGetTextWithMutex-8          3833086           311.2 ns/op        40 B/op          2 allocs/op
PASS
coverage: 100.0% of statements
ok      github.com/ynwd/monorepo/Documents/apps/cms/cmd 6.332s

Data Races di Golang: Fixing with Mutex

ynwd — Sat, 13 Nov 2021 05:39:05 +0000

Sebelumnya, kita telah membahas data race di golang dan channel. Sekarang kita akan mencoba memperbaiki data races dengan mutex.

Tapi sebelumnya, kita akan menambahkan sebuah struct text serta getter-setter-nya dan mengubah fungsi getText(), menjadi seperti ini:

package main

import (
    "fmt"
)

func getText() string {
    i := text{txt: "hi"}
    go func() {
        i.Set("hello")
    }()
    return i.Get()
}

type text struct {
    txt string
}

func (t *text) Set(txt string) {
    t.txt = txt
}

func (t *text) Get() string {
    return t.txt
}

func main() {
    fmt.Println(getText())
}

Kalau dilihat secara sequence diagram, ia mirip dengan kode sebelumnya.

Go routine #1 : main()
Go routine #2 : fungsi di mana i.Set() dipanggil.

Dan jika kita jalankan dengan -race:

go run -race main.go

Maka ia juga akan menghasilkan warning:

hi
==================
WARNING: DATA RACE
Write at 0x00c000012230 by goroutine 7:
  main.(*text).Set()
      /Users/pro/Documents/apps/cms/cmd/main.go:20 +0x33
  main.getText.func1()
      /Users/pro/Documents/apps/cms/cmd/main.go:10 +0x2e

Previous read at 0x00c000012230 by main goroutine:
  main.(*text).Get()
      /Users/pro/Documents/apps/cms/cmd/main.go:24 +0xda
  main.getText()
      /Users/pro/Documents/apps/cms/cmd/main.go:12 +0xf1
  main.main()
      /Users/pro/Documents/apps/cms/cmd/main.go:28 +0x24

Goroutine 7 (running) created at:
  main.getText()
      /Users/pro/Documents/apps/cms/cmd/main.go:9 +0xd0
  main.main()
      /Users/pro/Documents/apps/cms/cmd/main.go:28 +0x24
==================
Found 1 data race(s)
exit status 66

Solusi dengan mutex

Mutex gunanya untuk mencegah agar sebuah variabel tidak diakses secara bersamaan.

Implementasinya sangat mudah. Kita tinggal menempatkan saja method Lock dan Unlock di variabel yang terkena data races.

package main

import (
    "fmt"
    "sync"
)

func getText() string {
    i := text{txt: "hi"}
    go func() {
        i.Set("hello")
    }()
    return i.Get()
}

type text struct {
    txt   string
    mutex sync.Mutex
}

func (t *text) Set(txt string) {
    t.mutex.Lock()
    defer t.mutex.Unlock()
    t.txt = txt
}

func (t *text) Get() string {
    t.mutex.Lock()
    defer t.mutex.Unlock()
    return t.txt
}

func main() {
    fmt.Println(getText())
}

Jika kita jalankan dengan -race, hasilnya:

$ go run -race main.go                                                     main*
hi

Yang menjadi pertanyaan: mengapa hasilnya tetap hi?

Jawabannya adalah: karena go routine #1 (main), selesainya lebih dulu dan langsung exit.

Walaupun go routine ke-2 sedang berjalan, karena go routine #1 sudah exit duluan, ya sudah, program selesai.

Data Races di Golang: Fixing with Channels

ynwd — Thu, 11 Nov 2021 01:43:17 +0000

Pada artikel sebelumnya, kita telah memperbaiki data race dengan WaitGroup.

Kali ini kita akan mencegah data race menggunakan channel.

Caranya sangat mudah.

package main

import (
    "fmt"
)

func getText() string {
    t := "hi"
    done := make(chan bool)

    // go routine #2
    go func() {
        t = "hello"
        done <- true
    }()

    <-done
    return t
}

// go routine #1
func main() {
    fmt.Println(getText())
}

Source code: https://play.golang.org/p/INwBrA67cCu

Jalankan dengan -race:

$ go run -race main.go                                                                                 
hello

Dan warning DATA RACE pun tidak muncul lagi.

Data Races di Golang: Fixing with WaitGroup

ynwd — Thu, 11 Nov 2021 01:14:18 +0000

Pada artikel sebelumnya, telah kita bahas data races di golang. Kali ini kita akan mencegahnya agar tidak terjadi menggunakan sync.WaitGroup.

Caranya cukup mudah.

package main

import (
    "fmt"
    "sync"
)

func getText() string {
    t := "hi"
    var waitgroup sync.WaitGroup
    waitgroup.Add(1)

    // go routine #2
    go func() {
        t = "hello"
        waitgroup.Done()
    }()

    waitgroup.Wait()
    return t
}

// go routine #1
func main() {
    fmt.Println(getText())
}

Source code: https://play.golang.org/p/lYasbbWmB0j

Jalankan dengan -race:

$ go run -race main.go                                                                                  main*
hello

Dan warning DATA RACE pun tidak muncul lagi.

Data Races di Golang

ynwd — Wed, 10 Nov 2021 06:48:22 +0000

Data race adalah kondisi ketika sebuah variable diakses oleh dua go routine yang berjalan secara bersamaan (concurrent).

Mari kita lihat contohnya.

Source code: https://play.golang.org/p/4uWsRaxBs79

Jika kode diatas kita jalankan secara biasa, hasilnya "hi". Seolah-olah tidak terjadi masalah.

$ go run main.go
hi

Lalu, bagaimana cara melakukan simulasi agar terjadi race condition?

Simulasi data race

Untungnya, go sudah menyediakan cara agar kita melakukan simulasi data race.

Jalankan program dengan -race

$ go run -race main.go

Hasilnya:

hi
==================
WARNING: DATA RACE
Write at 0x00c000118210 by goroutine 7:
  main.getText.func1()
      /Users/pro/Documents/apps/cms/cmd/main.go:9 +0x30

Previous read at 0x00c000118210 by main goroutine:
  main.getText()
      /Users/pro/Documents/apps/cms/cmd/main.go:12 +0xda
  main.main()
      /Users/pro/Documents/apps/cms/cmd/main.go:17 +0x24

Goroutine 7 (running) created at:
  main.getText()
      /Users/pro/Documents/apps/cms/cmd/main.go:8 +0xd0
  main.main()
      /Users/pro/Documents/apps/cms/cmd/main.go:17 +0x24
==================
Found 1 data race(s)
exit status 66

Pembahasan error

Mari kita bahas satu persatu

Blok #1

WARNING: DATA RACE
Write at 0x00c000118210 by goroutine 7:
  main.getText.func1()
      /Users/pro/Documents/apps/cms/cmd/main.go:9 +0x30

Menjelaskan di mana data race terjadi: line ke-9.

Blok #2

Previous read at 0x00c000118210 by main goroutine:
  main.getText()
      /Users/pro/Documents/apps/cms/cmd/main.go:12 +0xda
  main.main()
      /Users/pro/Documents/apps/cms/cmd/main.go:17 +0x24

Menjelaskan di mana variable tersebut sudah terpanggil: line ke-12.

Blok #3

Goroutine 7 (running) created at:
  main.getText()
      /Users/pro/Documents/apps/cms/cmd/main.go:8 +0xd0
  main.main()
      /Users/pro/Documents/apps/cms/cmd/main.go:17 +0x24

Menjelaskan di mana go routine tersebut dibuat: line ke-8.