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(¶ms); 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(¶ms); 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 incompletepc spec is incompleteat least 1 price row is requiredduplicate 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),
),
)
This gives one endpoint three possible behaviors:
- return JSON for API-style requests
- return only the table fragment for HTMX partial updates
- return the full page layout for a normal page load
That keeps the route surface smaller while still supporting both page rendering and data access.
Part 3 Summary
At this point, the full stack is in place:
- GORM models define the data shape
- Fiber binds query, URI, and form data cleanly
- shared services make the database available to handlers
- count and page data can be fetched concurrently
- validation and business errors stay explicit
- HTMX headers let one route serve full pages, partial HTML, or JSON
With those pieces added to the UI from Part 1 and Part 2, the result is a complete pure Go admin workflow.
If you want the full boilerplate, the complete source is here: