Velocity v0.45: React, Vue, MySQL, and a lot of quiet hardening

Velocity just crossed v0.45.0. This isn't a launch post. It's a "what actually shipped" post for people who've been watching the repo.

The thesis still holds

One framework. Auth, ORM, queues, cache, mail, storage, broadcasting, gRPC. One config story. Driver swap between dev and prod via env vars. Zero refactor.

The last five releases were about widening the doors: more frontend stacks, more databases, more places to plug in real production tooling without rewriting your app.

Two frontend starter templates: React and Vue

Velocity uses Inertia.js as its view layer. You write a Go controller, return view.Render(ctx, "Dashboard", props), and your frontend handles the rest. Until now the official starter shipped React only. Now there are two:

• velocity-template-react: Inertia, React, Vite, TypeScript.
• velocity-template-vue: Inertia, Vue 3, Vite, TypeScript.

Both share the same vel CLI scaffold. Both share the same backend code. The Go side doesn't know or care which one you picked.

Inertia SSR is now wired through bond.HTTPGateway, so first-load HTML comes back rendered server-side and the CSP nonce is auto-stamped onto the page-data script. No manual SSR plumbing on your end.

The frontend stack is now a prompt in vel new. Pick React or Vue at scaffold time, the rest of the project shape is identical:

If you've been waiting for Vue support before trying Velocity, it's here.

MySQL driver in the ORM

orm already supported Postgres and SQLite. v0.45 adds MySQL as a first-class driver:

# .env
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=acme
DB_USERNAME=root
DB_PASSWORD=secret

The point isn't "we support MySQL." The point is the framework's promise of driver swap with zero refactor now covers the three databases most Go shops actually run in production.

ORM transaction hooks you can trust

err := m.Transaction(ctx, func(ctx context.Context) error {
    user, err := (User{}).Create(ctx, map[string]any{
        "email": "ada@example.com",
    })
    if err != nil {
        return err
    }
    return orm.OnCommit(ctx, func(ctx context.Context) error {
        return events.Dispatch(ctx, UserRegistered{ID: user.ID})
    })
})

orm.OnCommit, orm.OnRollback, and orm.OnCommitFailure now fire exactly when their names say. No surprise dispatches mid-transaction. Models can also implement AfterCommitHook / AfterRollbackHook if a per-model side-effect is the right place for the work. This pairs with the new context-through-everything change: context.Context propagates through every transaction-aware entry point and every event callback, which means traces, deadlines, and cancellation finally compose end-to-end.

The bulk-write path got the same treatment. WithBulkLock and atomic ID capture via RETURNING on Postgres mean model hooks fire correctly on CreateMany and friends without races.

Trace IDs survive the queue boundary

If a request enqueues a job, the trace ID is now persisted on the wire and rebuilt on the worker side. Same trace in your logs across the HTTP handler and the worker handler, no glue code.

The router and gRPC sides now use a single three-field trace convention (trace_id, span_id, parent_id), with a WithFullContext helper for handlers that need to forward it manually.

Security pass

A few things worth calling out:

• New crypto.Encryptor is AEAD with AAD binding. The old encryptor still works; the new one is opt-in.
• str.Random now uses crypto/rand. Previous implementation was sufficient for IDs but not for tokens. Fixed.
• The regex validation rule rejects ReDoS-prone patterns at compile time. If you've been routing user-supplied regexes through validation, that's now a build-time error instead of a production hang.
• Redis queue moveDelayedJobs is hardened against context cancellation and panics. No more silent job loss on shutdown.

Operational glue: gRPC scaffold

./vel make:grpc:service Billing
./vel make:grpc:rpc Billing CreateInvoice
./vel make:grpc:gen

The gRPC layer was already in the framework. v0.45 makes scaffolding it feel like the rest of the CLI. NewServer and NewGateway defaults now load from env via LoadConfig, so the same service binary works in dev and prod without code changes.

Next

The visible work is React, Vue, MySQL. The invisible work is everything around it that means you can actually run this in production without inventing your own observability stack. That's the part that matters more.