ColaFanta

Posted on May 7

Go Admin Dashboard for E-Commerce with HTMX, Templ UI, and GORM - Part 3

#go #templ #htmx #shadcn

This is the final part of the series. In Part 1 and Part 2, the focus was mostly on the UI layer. In this part, the missing backend pieces come together: database models, CRUD handlers, parameter binding, shared services, and response handling.

As in the previous articles, the examples below are intentionally simplified. They are based on the structure of this codebase, but they are written as tutorial-style pseudocode so the main ideas stay easy to follow.

GORM Generic Interface

This project uses GORM's generic API, which keeps queries type-safe and makes it easier to see which model is being queried.

For example, a product model can be declared like this:

type Product struct {
    gorm.Model

    Name        string `gorm:"not null"`
    Description string `gorm:"not null"`
    Brand       string `gorm:"not null"`
    Category    string `gorm:"not null"`
    Skus        []Sku  `gorm:"constraint:OnUpdate:CASCADE,OnDelete:CASCADE"`
}

Then queries can be written with gorm.G[T]:

func getProductByID(c fiber.Ctx, db *gorm.DB, id uint) (Product, error) {
    return gorm.G[Product](db).
        Where("id = ?", id).
        First(c)
}

The same style works for lists as well:

func listProducts(c fiber.Ctx, db *gorm.DB) ([]Product, error) {
    return gorm.G[Product](db).
        Order("id desc").
        Find(c)
}

That is the main benefit of the generic interface in this kind of project. The query code stays compact, and the model type stays visible.

CRUD parameter binding in Fiber v3

Fiber v3 makes parameter binding straightforward. The same handler style can read from query parameters, form bodies, and route params.

For example, a list page can bind query parameters like this:

type ProductListParams struct {
    Page   int    `query:"_page"`
    Size   int    `query:"_size"`
    Search string `query:"search"`
}

func getProductTableData(c fiber.Ctx) error {
    var params ProductListParams
    if err := c.Bind().All(&params); err != nil {
        return err
    }

    return c.SendStatus(fiber.StatusOK)
}

For a detail page, binding from the URL is just as simple:

type ProductIDParam struct {
    ID string `uri:"id"`
}

func getProductDetail(c fiber.Ctx) error {
    var params ProductIDParam
    if err := c.Bind().URI(&params); err != nil {
        return err
    }

    return c.SendStatus(fiber.StatusOK)
}

And for create or update actions, form binding works well:

type ProductFormPayload struct {
    ID          uint   `form:"id"`
    Name        string `form:"name"`
    Description string `form:"description"`
    Brand       string `form:"brand"`
    Category    string `form:"category"`
}

func upsertProduct(c fiber.Ctx) error {
    var payload ProductFormPayload
    if err := c.Bind().Form(&payload); err != nil {
        return err
    }

    return c.SendStatus(fiber.StatusNoContent)
}

This works well for CRUD APIs because the handler code stays close to the shape of the incoming request.

Share dependencies with Fiber services

Earlier parts avoided internal setup details, but one small backend pattern is useful to show here: shared services.

In this project, the database connection is registered as a Fiber service:

type DatabaseService struct {
    DB *gorm.DB
}

Then it is attached when the app starts:

app := fiber.New(fiber.Config{
    Services: []fiber.Service{
        &service.DatabaseService{DB: db},
    },
})

And handlers can retrieve it later:

func handler(c fiber.Ctx) error {
    db := fiber.MustGetService[*service.DatabaseService](
        c.App().State(),
        service.KeyDatabaseService,
    ).DB

    _ = db
    return c.SendStatus(fiber.StatusOK)
}

This keeps shared objects such as the database available without passing them through every function manually.

Get total count and page data concurrently

When building a paginated table, the backend usually needs two things:

the total number of matching records
the current page of records

This project uses go-opera to run those two queries concurrently.

The idea looks like this:

func ExecGetList[T any](c fiber.Ctx, q gorm.ChainInterface[T], page int, size int) opera.Result[GetListResponse[T]] {
    return opera.Do(func() GetListResponse[T] {
        countTask := opera.Async(c, func(ctx context.Context) opera.Result[int64] {
            return opera.Try(q.Count(ctx, "*"))
        })

        dataTask := opera.Async(c, func(ctx context.Context) opera.Result[[]T] {
            offset := (page - 1) * size
            return opera.Try(q.Offset(offset).Limit(size).Find(ctx))
        })

        count := opera.Await(c, countTask).Yield()
        data := opera.Await(c, dataTask).Yield()

        return GetListResponse[T]{
            Total: int(count),
            Data:  data,
        }
    })
}

The main point is simple: the page does not need to wait for the count query to finish before starting the data query.

For paginated admin tables, that pattern is a good fit.

Error handling

In CRUD code, the happy path is usually short. The real work is often in handling invalid input and business rules clearly.

At the router level, this project already turns validation failures into 400 Bad Request responses:

type structValidator struct {
    validate *validator.Validate
}

func (v *structValidator) Validate(out any) error {
    if err := v.validate.Struct(out); err != nil {
        return fiber.NewError(fiber.StatusBadRequest, err.Error())
    }
    return nil
}

Inside handlers, go-opera helps keep the flow compact:

func upsertProduct(c fiber.Ctx) error {
    return opera.Do(func() opera.Unit {
        var payload ProductFormPayload
        opera.MustPass(c.Bind().Form(&payload))

        if payload.Name == "" {
            opera.MustPass(fiber.NewError(fiber.StatusBadRequest, "name is required"))
        }

        opera.MustPass(saveProduct(payload))
        opera.MustPass(c.SendStatus(fiber.StatusNoContent))
        return opera.U
    }).Err()
}

And for more specific business rules, the same pattern works well. For example, the SKU handlers in this codebase return clear input errors such as:

phone spec is incomplete
pc spec is incomplete
at least 1 price row is required
duplicate price currency: USD

That kind of error is useful because it is both machine-friendly and readable enough for UI feedback.

Use HTMX headers to serve both page and JSON responses

One of the more useful patterns in this project is that a single route can serve more than one kind of client.

The HTMX helper functions inspect request headers such as HX-Request and HX-Boosted:

func IsHxRequest(c fiber.Ctx) bool {
    return HxStrToBool(c.Get("HX-Request"))
}

func IsHxBoosted(c fiber.Ctx) bool {
    return HxStrToBool(c.Get("HX-Boosted"))
}

func IsHtmlRequest(c fiber.Ctx) bool {
    acceptHeader := c.Get("Accept")
    return IsHxRequest(c) || IsHxBoosted(c) || strings.Contains(acceptHeader, "text/html")
}

Then middleware can decide how the same route should answer:

func IfNotHtmlSendData[T any](key T) fiber.Handler {
    return func(c fiber.Ctx) error {
        if !IsHtmlRequest(c) {
            data := fiber.Locals[any](c, key)
            return c.JSON(data)
        }
        return c.Next()
    }
}

That leads to a route composition like this:

app.Get("/products",
    getProductTableData,
    IfNotHtmlSendData(productTableKey),
    IfHx(IsHxBoostedForm,
        RenderTempl(ProductTable),
        RenderTempl(ProductTable, ProductTableLayout),
    ),
)