DEV Community

Cover image for 🌐 Golang RESTful API with Gin, Gorm, PostgreSQL 🐘
Truong Phung
Truong Phung

Posted on • Edited on

🌐 Golang RESTful API with Gin, Gorm, PostgreSQL 🐘

Comprehensive example of a Golang RESTful API service that uses gin for routing, gorm for ORM, and PostgreSQL as the database. This example includes the following PostgreSQL features: database and table creation, data insertion and querying, data partitioning, indexing, functions and stored procedures, triggers, views, CTEs, transactions, constraints, and JSON handling.

1. Project Setup

Assuming you have PostgreSQL (Quick Setup), Golang, and go mod set up, initialize the project:

mkdir library-api
cd library-api
go mod init library-api
Enter fullscreen mode Exit fullscreen mode

Project structure

/library-api
|-- db.sql
|-- main.go
|-- go.mod
Enter fullscreen mode Exit fullscreen mode

2. Install Dependencies

Install the necessary packages:

go get github.com/gin-gonic/gin
go get gorm.io/gorm
go get gorm.io/driver/postgres
Enter fullscreen mode Exit fullscreen mode

3. PostgreSQL Schema (db.sql)

Here is an SQL script for creating the database schema:

-- Create the library database.
CREATE DATABASE library;

-- Connect to the library database.
\c library;

-- Create tables.
CREATE TABLE authors (
    -- SERIAL: This is an auto-incrementing integer type. It’s shorthand for creating a column that uses a sequence to generate unique IDs. Behind the scenes, SERIAL creates an INTEGER column and an associated sequence that automatically increments. It has a range of -2,147,483,648 to 2,147,483,647 (32-bit).
    id SERIAL PRIMARY KEY,
    -- Defines a variable-length string, with a maximum length of 100 characters. It allows storing strings up to 100 characters in length but only uses as much space as required by the actual content, plus a byte or two for length storage, making it memory-efficient for shorter entries within the specified limit.
    name VARCHAR(100) NOT NULL UNIQUE,
    -- TEXT type in PostgreSQL is used to store variable-length text data without a defined limit. Unlike VARCHAR(n), which has a character limit, TEXT allows unlimited length (bounded by PostgreSQL's 1 GB per field limit). It’s ideal for storing longer text, like descriptions or content, without the need to specify an exact size.
    bio TEXT
);

CREATE TABLE books (
    id SERIAL PRIMARY KEY,
    title VARCHAR(200) NOT NULL,
    -- This creates a foreign key constraint:
    -- It establishes a relationship between author_id in the books table and the id column in the authors table, ensuring that each author_id corresponds to an existing id in the authors table.
    -- ON DELETE CASCADE: This means that if an author is deleted from the authors table, all related records in the books table (i.e., books written by that author) will automatically be deleted as well.
    author_id INTEGER REFERENCES authors(id) ON DELETE CASCADE,
    -- DATE type is used to store calendar dates (year, month, and day) without time information. It supports dates from 4713 BC to 5874897 AD and is suitable for fields like birth dates or other events where only the date is required, without the time.
    published_date DATE NOT NULL,
    description TEXT,
    -- the JSONB type stores JSON data in a binary format, optimized for fast querying and indexing. Unlike the plain JSON type, JSONB supports indexing for efficient data retrieval, making it ideal for handling complex JSON structures. It automatically removes whitespace and reorders keys, which enhances query performance but sacrifices the original formatting of JSON input.
    details JSONB
);

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    -- TIMESTAMP represents a date and time without a time zone. It’s precise down to microseconds and is often used to store exact dates and times in local time. The related TIMESTAMPTZ type, however, includes time zone data and adjusts automatically for different time zones when queried.
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- CREATE TABLE borrow_logs (
--     id SERIAL PRIMARY KEY,
--     user_id INTEGER REFERENCES users(id),
--     book_id INTEGER REFERENCES books(id),
--     borrowed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
--     returned_at TIMESTAMP
-- );

-- Create a partitioned table for borrow logs based on year.
-- The borrow_logs table is partitioned by year using PARTITION BY RANGE (borrowed_at).
CREATE TABLE borrow_logs (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    book_id INTEGER REFERENCES books(id),
    borrowed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    returned_at TIMESTAMP
) PARTITION BY RANGE (borrowed_at);

-- Create partitions for each year.
-- Automatic Routing: PostgreSQL automatically directs INSERT operations to the appropriate partition (borrow_logs_2023 or borrow_logs_2024) based on the borrowed_at date.
CREATE TABLE borrow_logs_2023 PARTITION OF borrow_logs
    FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

CREATE TABLE borrow_logs_2024 PARTITION OF borrow_logs
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
-- Benefit: This helps in improving query performance and managing large datasets by ensuring that data for each year is stored separately.

-- Important Node: 
-- If you try to insert a new record into the borrow_logs table with a borrowed_at date that does not fall within the range of any existing partitions, PostgreSQL will raise an error like folowing:
-- ERROR: no partition of relation "borrow_logs" found for row
-- DETAIL: Failing row contains (1, 1, 1, 2022-12-31 00:00:00, null).
-- How to Handle This:
-- 1. Add a Default Partition: You can create a default partition to store any data that doesn't match the existing ranges:
CREATE TABLE borrow_logs_default PARTITION OF borrow_logs DEFAULT;
-- 2 Create a New Partition: If you expect data from a different year, you should create a new partition for that year:
CREATE TABLE borrow_logs_2022 PARTITION OF borrow_logs FOR VALUES FROM ('2022-01-01') TO ('2023-01-01');


-- Indexes for faster searching.
CREATE INDEX idx_books_published_date ON books (published_date);
CREATE INDEX idx_books_details ON books USING GIN (details);
-- GIN Index (Generalized Inverted Index).  It is particularly useful for indexing columns with complex data types like arrays, JSONB, or text search fields

-- About Indexing In PostgreSQL, GIN (Generalized Inverted Index) indexes are designed for fast text searches and JSONB queries by indexing entire sets of values, making them ideal for full-text search, array, and JSONB fields. GIN indexes can handle complex data types efficiently, allowing fast lookups across unstructured data like documents.
-- Other common PostgreSQL index types include:
-- BTREE: The default index type, used for most general-purpose indexing with ordered data, like numbers and dates.
-- HASH: Ideal for simple equality checks but less commonly used due to limited performance improvements.
-- GiST (Generalized Search Tree): Useful for complex data types, like geometric data, allowing range queries and nearest-neighbor searches.
-- SP-GiST (Space-Partitioned GiST): Suited for advanced, irregular data, often used with spatial and natural language data.
-- BRIN (Block Range INdex): Best for very large datasets with sequential data where indexing every row would be inefficient.
-- Each type is optimized for specific use cases and data structures, enabling efficient querying tailored to different data patterns.

-- Add a full-text index to the title and description of books
CREATE INDEX book_text_idx ON books USING GIN (to_tsvector('english', title || ' ' || description));
-- to_tsvector('english', ...) converts the concatenated title and description fields into a Text Search Vector (tsv) suitable for full-text searching.
-- The || operator concatenates the title and description fields, so both fields are indexed together for searching.
-- 'english' specifies the language dictionary, which helps with stemming and stop-word filtering.


-- Create a simple view for books with author information.
CREATE VIEW book_author_view AS
SELECT books.id AS book_id, books.title, authors.name AS author_name
FROM books
JOIN authors ON books.author_id = authors.id;

-- Create a view to get user borrow history
CREATE VIEW user_borrow_history AS
SELECT
    u.id AS user_id,
    u.name AS user_name,
    b.title AS book_title,
    bl.borrowed_at,
    bl.returned_at
FROM
    users u
    JOIN borrow_logs bl ON u.id = bl.user_id
    JOIN books b ON bl.book_id = b.id;

-- Use a CTE to get all active borrow logs (not yet returned)
WITH active_borrows AS (
    SELECT * FROM borrow_logs WHERE returned_at IS NULL
)
SELECT * FROM active_borrows;

-- Function to calculate the number of books borrowed by a user.
-- Creates a function that takes an INT parameter user_id and returns an INT value. If the function already exists, it will replace it.
CREATE OR REPLACE FUNCTION get_borrow_count(user_id INT) RETURNS INT AS $$
    -- $1 is a placeholder for the first input. When the function is executed, PostgreSQL replaces $1 with the actual user_id value that is passed in by the caller.
    SELECT COUNT(*) FROM borrow_logs WHERE user_id = $1;
$$ LANGUAGE SQL;
-- AS $$ ... $$: This defines the body of the function between the dollar signs ($$).
-- LANGUAGE SQL: Specifies that the function is written in SQL.


-- Trigger to log activities.
CREATE TABLE activity_logs (
    id SERIAL PRIMARY KEY,
    description TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- This function returns a TRIGGER which will be used for later executions
CREATE OR REPLACE FUNCTION log_activity() RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO activity_logs (description)
    -- NEW refers to the new row being inserted or modified by the triggering event.
    VALUES ('A borrow_log entry has been added with ID ' || NEW.id);
    -- The function returns NEW, which means that the new data will be used as it is after the trigger action.
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
-- It uses plpgsql, which is a procedural language in PostgreSQL (commands between BEGIN END) 

CREATE TRIGGER log_borrow_activity
AFTER INSERT ON borrow_logs
FOR EACH ROW EXECUTE FUNCTION log_activity();

-- Add a JSONB column to store metadata
ALTER TABLE books ADD COLUMN metadata JSONB;
-- Example metadata: {"tags": ["fiction", "bestseller"], "page_count": 320}
Enter fullscreen mode Exit fullscreen mode

4. Golang Code (main.go)

Here’s a complete example of a RESTful API using Gin and GORM:

package main

import (
    "net/http"
    "strconv"
    "time"

    "github.com/gin-gonic/gin"
    "gorm.io/driver/postgres"
    "gorm.io/gorm"
)

type Author struct {
    ID   uint   `gorm:"primaryKey"`
    Name string `gorm:"not null;unique"`
    Bio  string
}

type Book struct {
    ID            uint                   `gorm:"primaryKey"`
    Title         string                 `gorm:"not null"`
    AuthorID      uint                   `gorm:"not null"`
    PublishedDate time.Time              `gorm:"not null"`
    Details       map[string]interface{} `gorm:"type:jsonb"`
}

type User struct {
    ID        uint   `gorm:"primaryKey"`
    Name      string `gorm:"not null"`
    Email     string `gorm:"not null;unique"`
    CreatedAt time.Time
}

type BorrowLog struct {
    ID         uint      `gorm:"primaryKey"`
    UserID     uint      `gorm:"not null"`
    BookID     uint      `gorm:"not null"`
    BorrowedAt time.Time `gorm:"default:CURRENT_TIMESTAMP"`
    ReturnedAt *time.Time
}

var db *gorm.DB

func initDB() {
    dsn := "host=localhost user=postgres password=yourpassword dbname=library port=5432 sslmode=disable"
    var err error
    db, err = gorm.Open(postgres.Open(dsn), &gorm.Config{})
    if err != nil {
        panic("failed to connect to database")
    }

    // Auto-migrate models.
    db.AutoMigrate(&Author{}, &Book{}, &User{}, &BorrowLog{})
}

func main() {
    initDB()
    r := gin.Default()

    r.POST("/authors", createAuthor)
    r.PUT("/authors/:id", updateAuthor)    // Update an author's information.
    r.DELETE("/authors/:id", deleteAuthor) // Delete an author by ID.
    r.POST("/books", createBook)
    r.POST("/users", createUser)
    r.POST("/borrow", borrowBook)
    r.GET("/borrow/user/:id/count", getBorrowCount)
    r.GET("/borrow/user/:id/logs", getBorrowLogs)
    r.GET("/borrow_logs", listBorrowLogs) // List borrow logs with pagination.
    r.GET("/books_with_author", listBooks)

    r.Run(":8080")
}

func createAuthor(c *gin.Context) {
    var author Author
    if err := c.ShouldBindJSON(&author); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }
    if err := db.Create(&author).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, author)
}

func updateAuthor(c *gin.Context) {
    var author Author

    // Bind JSON data.
    if err := c.ShouldBindJSON(&author); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    // Find the author by ID and update.
    if err := db.Model(&Author{}).Where("id = ?", c.Param("id")).Updates(&author).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, gin.H{"message": "Author updated successfully"})
}

func deleteAuthor(c *gin.Context) {
    if err := db.Delete(&Author{}, c.Param("id")).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, gin.H{"message": "Author deleted successfully"})
}

func createBook(c *gin.Context) {
    var book Book
    if err := c.ShouldBindJSON(&book); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }
    if err := db.Create(&book).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, book)
}

func createUser(c *gin.Context) {
    var user User
    if err := c.ShouldBindJSON(&user); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }
    if err := db.Create(&user).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, user)
}

// The Golang code does not need changes specifically to use the partitioned tables; the partitioning is handled by PostgreSQL
// you simply insert into the borrow_logs table, and PostgreSQL will automatically route the data to the correct partition.
func borrowBook(c *gin.Context) {
    var log BorrowLog
    if err := c.ShouldBindJSON(&log); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    tx := db.Begin()
    if err := tx.Create(&log).Error; err != nil {
        tx.Rollback()
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    tx.Commit()
    c.JSON(http.StatusOK, log)
}

func getBorrowCount(c *gin.Context) {
    userID := c.Param("id")
    var count int
    if err := db.Raw("SELECT get_borrow_count(?)", userID).Scan(&count).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, gin.H{"borrow_count": count})
}

// When querying a partitioned table in PostgreSQL using Golang, no changes are needed in the query logic or code.
// You interact with the parent table (borrow_logs in this case) as you would with any normal table, and PostgreSQL automatically manages retrieving the data from the appropriate partitions.
// Performance: PostgreSQL optimizes the query by scanning only the relevant partitions, which can significantly speed up queries when dealing with large datasets.
// Here’s how you might query the borrow_logs table using GORM, even though it’s partitioned:
func getBorrowLogs(c *gin.Context) {
    var logs []BorrowLog
    if err := db.Where("user_id = ?", c.Param("user_id")).Find(&logs).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, logs)
}

// A common approach for cursor-based pagination is to use a unique field like ID or a timestamp (e.g., BorrowedAt).
// The client will request a set of results, and if there are more results to be fetched, the response will include a next_cursor that the client can use in subsequent requests.
// To use this endpoint.
// 1. First Request: GET /borrow_logs?pageSize=5 , Response will include logs and next_cursor (e.g., 2024-01-15T08:00:00Z).
// 2. GET /borrow_logs?pageSize=5&next_cursor=2024-01-15T08:00:00Z , This request will fetch the next set of borrow logs where BorrowedAt is greater than 2024-01-15T08:00:00Z.
func listBorrowLogs(c *gin.Context) {
    var logs []BorrowLog

    // Get the cursor from query parameters.
    nextCursor := c.Query("next_cursor")
    pageSize := c.DefaultQuery("pageSize", "10")
    pageSizeInt, _ := strconv.Atoi(pageSize)

    query := db.Limit(pageSizeInt).Order("borrowed_at ASC")

    // If a cursor is provided, fetch records after the given timestamp.
    if nextCursor != "" {
        cursorTime, err := time.Parse(time.RFC3339, nextCursor)
        if err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": "Invalid cursor format"})
            return
        }
        query = query.Where("borrowed_at > ?", cursorTime)
    }

    if err := query.Find(&logs).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    // Prepare the next cursor based on the last record's BorrowedAt timestamp.
    var newCursor string
    if len(logs) > 0 {
        lastLog := logs[len(logs)-1]
        newCursor = lastLog.BorrowedAt.Format(time.RFC3339)
    }

    // Respond with the logs and the new cursor.
    c.JSON(http.StatusOK, gin.H{
        "logs":        logs,
        "next_cursor": newCursor,
    })
}

func listBooks(c *gin.Context) {
    var books []Book
    db.Preload("Author").Find(&books)
    c.JSON(http.StatusOK, books)
}
Enter fullscreen mode Exit fullscreen mode

Explanation of Golang Code:

  • Database Initialization: Connects to the PostgreSQL database and initializes GORM.
  • Routes: Defines routes for creating authors, books, users, borrowing books, and fetching the borrow count.
  • Transaction Handling: Uses a transaction when borrowing a book to ensure consistency.
  • Preload: Uses GORM’s Preload to join related tables (authors with books).
  • Stored Procedure Call: Uses db.Raw to call a custom PostgreSQL function for calculating the borrow count.

5. Running the API

  • Run the PostgreSQL SQL script to create tables, indexes, views, functions, and triggers.
  • Start the Golang server using

     go run main.go
    

Now, you have a comprehensive Golang RESTful API that covers various PostgreSQL features, making it a robust example for learning or interviews.

6. Adding some more features.

Let's enhance the Golang RESTful API example with additional PostgreSQL features by incorporating Views, CTEs (Common Table Expressions), full-text indexing, and JSON handling. Each of these features will be demonstrated with relevant PostgreSQL table definitions and Golang code to interact with them.

Data Schema for this part is already prepared from last section, so we just need to add more golang code main.go.

// Querying the user_borrow_history View:
func getUserBorrowHistory(c *gin.Context) {
    var history []struct {
        UserID     uint       `json:"user_id"`
        UserName   string     `json:"user_name"`
        BookTitle  string     `json:"book_title"`
        BorrowedAt time.Time  `json:"borrowed_at"`
        ReturnedAt *time.Time `json:"returned_at,omitempty"`
    }

    if err := db.Raw("SELECT * FROM user_borrow_history WHERE user_id = ?", c.Param("user_id")).Scan(&history).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, history)
}

// Using a CTE in a Query:
func getActiveBorrows(c *gin.Context) {
    var logs []BorrowLog
    query := `
    WITH active_borrows AS (
        SELECT * FROM borrow_logs WHERE returned_at IS NULL
    )
    SELECT * FROM active_borrows WHERE user_id = ?`

    if err := db.Raw(query, c.Param("user_id")).Scan(&logs).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, logs)
}

// Full-Text Search in books:
func searchBooks(c *gin.Context) {
    var books []Book
    searchQuery := c.Query("q")
    query := `
    SELECT * FROM books
    WHERE to_tsvector('english', title || ' ' || description) @@ plainto_tsquery('english', ?)
    `

    if err := db.Raw(query, searchQuery).Scan(&books).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, books)
}

// Handling JSONB Data:
func updateBookMetadata(c *gin.Context) {
    var metadata map[string]interface{}
    if err := c.ShouldBindJSON(&metadata); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    bookID := c.Param("book_id")
    if err := db.Model(&Book{}).Where("id = ?", bookID).Update("metadata", metadata).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, gin.H{"status": "metadata updated"})
}

// Can query a specific field from a JSONB column using the ->> operator to extract a value as text:
func getBookTags(c *gin.Context) {
    var tags []string
    bookID := c.Param("book_id")
    query := `SELECT metadata->>'tags' FROM books WHERE id = ?`

    if err := db.Raw(query, bookID).Scan(&tags).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, gin.H{"tags": tags})
}

// To add or update fields in a JSONB column, use the jsonb_set function:
func updateBookPageCount(c *gin.Context) {
    bookID := c.Param("book_id")
    var input struct {
        PageCount int `json:"page_count"`
    }

    if err := c.ShouldBindJSON(&input); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    query := `
    UPDATE books
    SET metadata = jsonb_set(metadata, '{page_count}', to_jsonb(?::int), true)
    WHERE id = ?`

    if err := db.Exec(query, input.PageCount, bookID).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, gin.H{"status": "page count updated"})
}
Enter fullscreen mode Exit fullscreen mode

Summary of Features:

  • Views: Simplify access to data with user_borrow_history view, making complex joins easier to query.
  • CTEs: Use WITH clauses for organized queries like fetching active borrow logs.
  • Full-Text Index: Enhance search capabilities on books with a GIN index on to_tsvector.
  • JSON Handling:

    • Store and update rich metadata using the JSONB type.
    • getBookTags retrieves a specific JSON field (tags) from the metadata JSONB column.
    • updateBookPageCount updates or adds the page_count field in the metadata JSONB column.

    By using db.Raw and db.Exec for raw SQL with GORM, you can leverage PostgreSQL’s powerful features while maintaining GORM’s ORM capabilities for other parts of your application. This makes the solution both flexible and feature-rich.

7. Other advanced features

In this extended example, We will integrate the following features using Golang and PostgreSQL:

  1. VACUUM: Used for reclaiming storage occupied by dead tuples and preventing table bloat.
  2. MVCC: A concept that allows concurrent transactions by maintaining different versions of rows.
  3. Window Functions: Used for performing calculations across a set of table rows related to the current row.

1. Using VACUUM in Golang

VACUUM is typically used as a maintenance task, not directly from application code. However, you can run it using GORM’s Exec for housekeeping purposes:

func vacuumBooks(c *gin.Context) {
    if err := db.Exec("VACUUM ANALYZE books").Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, gin.H{"status": "Vacuum performed successfully"})
}
Enter fullscreen mode Exit fullscreen mode
  • VACUUM ANALYZE books: Reclaims storage and updates statistics used by the query planner for the books table.
  • Running VACUUM is generally done during off-peak hours or as part of a maintenance script rather than on each request.

2. Understanding MVCC (Multi-Version Concurrency Control)

PostgreSQL's MVCC allows concurrent transactions by keeping different versions of rows. Here’s an example of how to demonstrate MVCC behavior in Golang using transactions:

func updateBookTitle(c *gin.Context) {
    bookID := c.Param("book_id")
    var input struct {
        NewTitle string `json:"new_title"`
    }
    if err := c.ShouldBindJSON(&input); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    // Start a transaction to demonstrate MVCC
    tx := db.Begin()

    defer func() {
        if r := recover(); r != nil {
            tx.Rollback()
        }
    }()

    var book Book
    if err := tx.Set("gorm:query_option", "FOR UPDATE").First(&book, bookID).Error; err != nil {
        tx.Rollback()
        c.JSON(http.StatusNotFound, gin.H{"error": "Book not found"})
        return
    }

    // Simulate an update to demonstrate MVCC handling
    book.Title = input.NewTitle
    if err := tx.Save(&book).Error; err != nil {
        tx.Rollback()
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    // Commit the transaction
    tx.Commit()
    c.JSON(http.StatusOK, gin.H{"status": "Book title updated"})
}
Enter fullscreen mode Exit fullscreen mode
  • FOR UPDATE: Locks the selected row for updates during the transaction, preventing other transactions from modifying it until the current one finishes.
  • This ensures consistency during concurrent access, showcasing how MVCC allows concurrent reads but locks rows for updates.

3. Using Window Functions with GORM

Window functions are used to perform calculations over a set of table rows related to the current row. Here’s an example of using a window function to calculate the running total of borrowed books for each author:

func getAuthorBorrowStats(c *gin.Context) {
    var stats []struct {
        AuthorID       int    `json:"author_id"`
        AuthorName     string `json:"author_name"`
        TotalBorrows   int    `json:"total_borrows"`
        RunningTotal   int    `json:"running_total"`
    }

    query := `
    SELECT
        a.id AS author_id,
        a.name AS author_name,
        COUNT(bl.id) AS total_borrows,
        SUM(COUNT(bl.id)) OVER (PARTITION BY a.id ORDER BY bl.borrowed_at) AS running_total
    FROM authors a
    LEFT JOIN books b ON b.author_id = a.id
    LEFT JOIN borrow_logs bl ON bl.book_id = b.id
    GROUP BY a.id, a.name, bl.borrowed_at
    ORDER BY a.id, bl.borrowed_at
    `

    if err := db.Raw(query).Scan(&stats).Error; err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
        return
    }

    c.JSON(http.StatusOK, stats)
}
Enter fullscreen mode Exit fullscreen mode
  • SUM(COUNT(bl.id)) OVER (PARTITION BY a.id ORDER BY bl.borrowed_at): A window function that calculates the running total of borrowed books for each author, ordered by the borrowed_at date.
  • This can provide insights such as how the borrowing trends change over time for each author.

If you found this helpful, let me know by leaving a πŸ‘ or a comment!, or if you think this post could help someone, feel free to share it! Thank you very much! πŸ˜ƒ

Top comments (4)

Collapse
 
dreama profile image
Dream

This looks like an incredibly comprehensive guide! One question though: do you have any plans to cover potential optimizations for larger databases using PostgreSQL, beyond partitioning? I'd love to see more on that in a future post!

Collapse
 
truongpx396 profile image
Truong Phung

Thank you Dream for your feedback and good question, I'll cover that topic in a future post and get back to you when It's ready πŸ˜ƒ

Collapse
 
pmp profile image
ΠœΠΈΡ€Π·Π°Π»ΠΈ ΠŸΠΈΡ€ΠΌΠ°Π³ΠΎΠΌΠ΅Π΄ΠΎΠ²

Why not place large queries in stored procedures?

SELECT
a.id AS author_id,
a.name AS author_name,
COUNT(bl.id) AS total_borrows,
SUM(COUNT(bl.id)) OVER (PARTITION BY a.id ORDER BY bl.borrowed_at) AS running_total
FROM authors a
LEFT JOIN books b ON b.author_id = a.id
LEFT JOIN borrow_logs bl ON bl.book_id = b.id
GROUP BY a.id, a.name, bl.borrowed_at
ORDER BY a.id, bl.borrowed_at

This approach is not recommended in go?
call getAuthorBorrowStats();

Collapse
 
truongpx396 profile image
Truong Phung

Hello ΠœΠΈΡ€Π·Π°Π»ΠΈ ΠŸΠΈΡ€ΠΌΠ°Π³ΠΎΠΌΠ΅Π΄ΠΎΠ², thank you for your feedback and good question, actually each approach has its own pros & cons, below is the breakdowns

When deciding whether to place a query like the one you've shared in a database stored procedure or keep it within Golang code, the choice depends on several factors, such as maintainability, performance, team practices, and flexibility. Below is a comparison of both approaches to help you decide:

Option 1: Store the Query in a Stored Procedure (PostgreSQL)

<> Advantages:

  1. Performance:
  2. Stored procedures are compiled and stored on the database server, which may improve performance for complex queries.
  3. Reduces network round trips as the query is executed directly on the database.

  4. Reusability:

  5. The stored procedure can be reused across different applications and languages, providing a single source of truth for this query.

  6. Encapsulation:

  7. Complex business logic or data transformations are encapsulated in the database, keeping the application logic cleaner.

  8. Security:

  9. Permissions can be managed at the database level, limiting direct access to tables and exposing only the procedure.

<> Disadvantages:

  1. Harder to Maintain:
  2. Debugging and versioning stored procedures can be challenging, especially in team workflows.
  3. If you need to make frequent changes, stored procedures add overhead as they require database deployment processes.

  4. Tight Coupling:

  5. Business logic ends up tightly coupled with the database, making it harder to migrate to other databases.

  6. Limited Tooling:

  7. Code tools (like linters, debuggers, or unit tests) don't work well with stored procedures compared to Golang code.

  8. Portability Issues:

  9. Stored procedures are database-specific; moving to another database requires rewriting.

Option 2: Keep the Query in Golang Code

<> Advantages:

  1. Maintainability:
  2. Easier to version, review, and test queries since they are part of the application's codebase.
  3. Better alignment with modern CI/CD pipelines.

  4. Flexibility:

  5. Queries can be constructed dynamically, allowing conditional logic or parameterization in Golang.

  6. Changes can be made quickly without requiring database migrations.

  7. Tooling Support:

  8. IDEs, linters, and debuggers provide better support for queries within Golang code.

  9. Separation of Concerns:

  10. Keeping queries in code maintains a clear boundary between the database layer and application layer.

  11. Portability:

  12. Makes it easier to change database systems if needed since queries can be adapted in the application layer.

<> Disadvantages:

  1. Performance Overhead:
  2. For very complex queries, keeping them in code might introduce slight overhead due to query parsing and network latency.

  3. Query Duplication:

  4. If the query is reused in multiple places, it might result in code duplication unless refactored into helper functions or packages.

  5. Security Risks:

  6. Improper handling of user input might lead to SQL injection if queries are not parameterized.

** Recommendation

In modern application development, keeping queries in the Golang code is generally preferred for the following reasons:

  1. It aligns with clean architecture principles, promoting separation of concerns.

  2. It allows better integration with modern tooling, version control, and CI/CD pipelines.

  3. It improves maintainability, as changes to queries don't require database migrations.

However, use stored procedures in the following cases:

  1. When performance optimization is critical for a highly complex query, and stored procedures provide measurable benefits.

  2. When the query logic needs to be reused across multiple services or applications.

  3. When you need to secure direct access to database tables.

** Final Note:

For this query, which is a bit complex (with aggregations, window functions, and grouping), I would recommend starting with placing it in Golang code and measuring its performance. If you encounter performance bottlenecks, consider moving it into a stored procedure for optimization.