danielgtaylor / danielgtaylor/huma

Adding gRPC support to existing Huma API - recommended approach?

Open
#1,003 0 comments 0 reactions 0 assignees View on GitHub
question
Dominant language
Go
Stars
4.4k
Forks
285
Avg merge
40m
Merged PRs (30d)
1

Description

### Context

I have a REST API built with Huma (~100 endpoints) that currently serves a web frontend. We now need to add gRPC support for backend-to-backend integrations while keeping the REST API for the frontend.

### The validation problem

Currently, we pushed validation into a deeper layer (use case input constructors) rather than using Huma struct tags. This was intentional - we wanted validation logic that works for both HTTP and future gRPC transports.

**Trade-off:** Our OpenAPI spec doesn't reflect validation constraints (no `minLength`, `minimum`, etc. in the generated spec), but validation is transport-agnostic.
```go
// Current approach - validation in constructor
type CreateAssignmentInput struct {
Title string
Points int
}

func NewCreateAssignmentInput(title string, points int) (*CreateAssignmentInput, error) {
// Validation here (works for HTTP, gRPC, events)
if title == "" || len(title) > 255 {
return nil, errors.New("title must be 1-255 characters")
}
if points < 0 || points > 1000 {
return nil, errors.New("points must be 0-1000")
}
return &CreateAssignmentInput{Title: title, Points: points}, nil
}
```

This kinda works but feels like im wasting Huma features and inherently creating an incomplete spec.

### Question

What's the recommended approach for adding gRPC while handling validation properly?

**Option 1: Dual transport with shared validation**
- Keep existing Huma REST handlers
- Add separate gRPC server
- Both call the same validation layer (use case constructors)
- Accept incomplete/innacurate OpenAPI spec

**Option 2: Move validation to Huma structs, duplicate for gRPC**
- Add Huma validation tags for accurate OpenAPI
- Duplicate validation in proto
- Accept maintaining validation in two places

### My Main Question is...

Do you have any patterns for keeping validation DRY across HTTP and gRPC transports while keeping accurate spec definition for both?

Or is accepting one of these trade-offs (incomplete spec vs duplicated validation) the pragmatic path forward?

Thanks for any guidance!

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.