This repository was archived by the owner on Dec 27, 2025. It is now read-only.
Separate JSON and protobuf representations in ConnectRPC/gRPC responses#67
Merged
lambdalisue merged 1 commit intomainfrom Dec 23, 2025
Merged
Conversation
…N and protobuf representations in responses Response objects now provide two distinct data access patterns: - response.data: Plain JSON with camelCase fields (via toJson) - response.raw: Original protobuf Message with $typeName metadata This separation addresses the mismatch between protobuf's snake_case convention and JavaScript's camelCase convention. Users working with JSON APIs get clean, serializable objects without protobuf metadata, while users needing protobuf-specific features retain full access to the original Message. The implementation retrieves message schemas from gRPC reflection (FileRegistry) and converts responses using @bufbuild/protobuf's toJson(). Error handling ensures graceful fallback to raw messages if conversion fails. Changes: - Add schema parameter to ConnectRpcResponseSuccessParams - Implement toJson conversion in ConnectRpcResponseSuccessImpl - Retrieve output schemas in all 4 RPC methods (call, serverStream, clientStream, bidiStream) - Match methods by localName (camelCase) instead of name (PascalCase) - Add comprehensive field name convention documentation - Add tests for schema conversion and error handling
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
response.dataproperty with plain JSON (camelCase fields, no$typeName)response.rawproperty with original protobuf Message (includes$typeName)toJson()from@bufbuild/protobufWhy
Users working with ConnectRPC/gRPC responses faced a mismatch between protobuf's
snake_casenaming convention and JavaScript'scamelCaseconvention. The original implementation returned raw protobuf Messages directly, which:snake_casefield names in JavaScript code$typeName) that complicated JSON serializationThis change addresses these issues by providing two distinct access patterns:
response.data: Plain JSON withcamelCasefields - suitable for logging, storage, and general JavaScript usageresponse.raw: Original protobuf Message with metadata - for users needing protobuf-specific features like field presence checkingThe implementation uses gRPC reflection to retrieve message schemas and converts responses via
@bufbuild/protobuf'stoJson(). Error handling ensures graceful fallback to raw messages if conversion fails, preventing API breakage.Test Plan
deno task verify- all 441 tests passtoJson()failsdataandrawusage