README.md

starterdata

Tier: Starter · Status: Full · Java original: firefly-starter-data · .NET project: FireflyFramework.Starter.Data

Overview

starterdata is the bring-your-own-DB starter. It composes startercore and leaves the persistence pool to the consumer — perfect for services that already own a *sql.DB / pgxpool.Pool configuration.

type Data struct {
    *startercore.Core
}

func New(cfg startercore.Config) *Data

StarterName defaults to "starter-data".

Quick start

import (
    "database/sql"

    _ "github.com/jackc/pgx/v5/stdlib"
    "github.com/fireflyframework/fireflyframework-go/migrations"
    "github.com/fireflyframework/fireflyframework-go/starterdata"
    "github.com/fireflyframework/fireflyframework-go/startercore"
)

func main() {
    db, _ := sql.Open("pgx", os.Getenv("DATABASE_URL"))
    if err := migrations.Run(ctx, db, migrations.NewFSSource(migrationFS, "db")); err != nil {
        log.Fatal(err)
    }

    d := starterdata.New(startercore.Config{AppName: "orders"})
    repo := newOrderRepo(db)
    orderscore.Register(d.Bus, repo)
    // … wire HTTP, run via d.NewApplication() …
}

Why a separate starter?

Three reasons:

1. The Core abstraction can't hold a typed *sql.DB without either pulling pgx into every service or losing type safety. starterdata lets the consumer keep their typed pool while still getting the standard Core facilities.
2. Services that don't need a database (read-side projections, thin BFFs, event consumers) should not be forced to depend on a DB driver. Use starterdata only when persistence is needed.
3. Migration timing is application-specific (some services run migrations elsewhere, some at startup) — leaving the choice in main.go keeps it explicit.

Testing

cd starterdata
go test ./...

Covers the wired Core being non-nil and the StarterName overrride.