DEV Community: ynwd

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.

UseEffect React Testing

ynwd — Sun, 07 Nov 2021 08:38:47 +0000

This is a modification of the App.tsx and App.test.tsx CRAs. It uses useEffect to get the text from the Golang API.

Source code: https://github.com/ynwd/mnrp
Live demo: https://fastro-319406.firebaseapp.com/

.
├── cloudbuild.yaml
├── cmd
│   ├── build
│   │   ├── index.gohtml
│   │   └── main.go
│   └── main.go
├── firebase.json
├── go.mod
├── internal
│   ├── app.go
│   └── app_test.go
├── package.json
├── serverless.go
└── web
    └── home
        ├── craco.config.js
        ├── package.json
        ├── public
        ├── src
        │   ├── App.css
        │   ├── App.test.tsx
        │   ├── App.tsx
        │   ├── index.css
        │   ├── index.tsx
        │   ├── logo.svg
        │   ├── react-app-env.d.ts
        │   ├── reportWebVitals.ts
        │   └── setupTests.ts
        ├── tailwind.config.js
        └── tsconfig.json

Backend

Golang API

package internal

import (
    "context"

    "github.com/fastrodev/fastrex"
)

func Handler(req fastrex.Request, res fastrex.Response) {
    res.Send("The best interface is no interface")
}

func CreateApp() fastrex.App {
    ctx := context.Background()
    app := fastrex.New()
    app.Ctx(ctx)
    app.Get("/api", Handler)
    return app
}

Entry point

package serverless

import (
    "net/http"

    "github.com/ynwd/mnrp/internal"
)

func Main(w http.ResponseWriter, r *http.Request) {
    internal.CreateApp().Serverless(true).ServeHTTP(w, r)
}

Frontend

App.tsx

import React, { useEffect, useState } from 'react';
import logo from './logo.svg';
import './App.css';

function App() {
  const [value, setValue] = useState("");
  useEffect(() => {
    async function getText() {
      let response = await fetch('/api')
      const d = await response.text()
      setValue(d)
    }
    getText()
  }, [value]);

  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <h3>
          {value}
        </h3>
      </header>
    </div>
  );
}

export default App;

App.test.tsx

import React from 'react';
import { rest } from 'msw';
import { setupServer } from 'msw/node';
import { render, screen } from '@testing-library/react';
import App from './App';

const server = setupServer(
  rest.get('/api', async (req, res, ctx) => {
    return res(ctx.text("The best interface is no interface"));
  })
);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('loads and displays greeting', async () => {
  render(<App />);
  const linkElement = await screen.findByText('The best interface is no interface');
  screen.debug()
  expect(linkElement).toBeInTheDocument();
});

How to setup golang backend and react frontend in a monorepo

ynwd — Wed, 20 Oct 2021 10:23:49 +0000

Previously, we have set up a frontend module using react and typescript in a monorepo.

Next, we will use the golang server to serve the built webapp.

.
├── go.mod
├── go.sum
├── main.go
├── package.json
└── web
    ├── components
    └── modules
        └── root
            ├── build
            │   ├── asset-manifest.json
            │   ├── favicon.ico
            │   ├── index.html
            │   ├── logo192.png
            │   ├── logo512.png
            │   ├── manifest.json
            │   ├── robots.txt
            │   └── static
            │       ├── css
            │       │   ├── main.33a5a96b.chunk.css
            │       │   └── main.33a5a96b.chunk.css.map
            │       └── js
            │           ├── 2.59f16c8b.chunk.js
            │           ├── 2.59f16c8b.chunk.js.LICENSE.txt
            │           ├── 2.59f16c8b.chunk.js.map
            │           ├── 3.93db3793.chunk.js
            │           ├── 3.93db3793.chunk.js.map
            │           ├── main.f7ff0158.chunk.js
            │           ├── main.f7ff0158.chunk.js.LICENSE.txt
            │           ├── main.f7ff0158.chunk.js.map
            │           ├── runtime-main.08d49f3a.js
            │           └── runtime-main.08d49f3a.js.map
            └── package.json

clone repo: https://github.com/ynwd/monorepo/tree/typescript

create services folder

mkdir -p internal/services

init golang app

go mod init github.com/ynwd/monorepo

downlod fastrex package

go get github.com/fastrodev/fastrex

this will generate go.mod file

module github.com/ynwd/monorepo

go 1.17

require github.com/fastrodev/fastrex v0.0.0-20211008073151-687f0b90ec18 // indirect

create golang app entry point

/* main.go */
package main

import (
    "github.com/fastrodev/fastrex"
)

func main() {
    app := fastrex.New()
    app.Template("web/modules/root/build/index.html")
    app.Static("web/modules/root/build")
    app.Get("/", func(req fastrex.Request, res fastrex.Response) {
        err := res.Render()
        if err != nil {
            panic(err)
        }
    })
    err := app.Listen(8080)
    if err != nil {
        panic(err)
    }
}

build react root module

npm run build -w @fstr/root

run golang server

go run main.go

You can see the final source code here: https://github.com/ynwd/monorepo/tree/fastrex