chore: introduce records.getFast method which skips serde layer #59
Conversation
WalkthroughThe pull request introduces a new method Changes
Sequence DiagramsequenceDiagram
participant Client
participant RecordsClient
participant API
Client->>RecordsClient: getFast(sheetId, request, options)
RecordsClient->>API: GET records with query parameters
alt Successful Response
API-->>RecordsClient: Return records data
RecordsClient-->>Client: Return serialized records
else Error Response
API-->>RecordsClient: Return error
RecordsClient->>Client: Throw specific error (BadRequest, NotFound)
end
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
src/wrapper/RecordsClient.ts (3)
125-129: Ensure the docstring clarifies which cases to prefergetFastvs.get.
While it's clear thatgetFastis meant to retrieve records without the overhead of deserialization, it would help maintainers and users if you explicitly document scenarios wheregetFastmight be more beneficial (e.g., performance-sensitive workflows) and any potential trade-offs (e.g., losing the type safety or validation of the fullgetmethod).
126-134: Consider extracting the query parameter construction to a shared helper function.
The code from lines 163 to 249 handles building a_queryParamsobject in a straightforward yet repetitive way. If other methods or future expansions require similar logic, moving these steps to a shared utility would reduce duplication and improve maintainability.+// Example structure: src/util/QueryParamBuilder.ts +export function buildQueryParams(request: Flatfile.GetRecordsRequest): Record<string, unknown> { + // shared logic for constructing query params +} -const _queryParams: Record<string, string | string[] | object | object[]> = {}; -// repeated lines to fill in the query params +const _queryParams = buildQueryParams(request);Also applies to: 135-318
251-273: Validate potential large responses for memory usage.
While this method avoids deserialization overhead, it might return significantly large payloads as raw data. Ensure that the client or calling services can handle such payloads efficiently in memory.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/wrapper/RecordsClient.ts(1 hunks)
🔇 Additional comments (1)
src/wrapper/RecordsClient.ts (1)
275-317: Error handling logic matches existing patterns.
The thrown errors (BareRequestError, NotFoundError, etc.) and fallback to FlatfileError follow the existing structure, keeping consistency across the codebase. This is good for maintainability and discoverability.
This PR introduces a
client.records.getFastmethod which skips the serde layer and returns the raw JSON from the records endpoint.A new method is introduced to prevent a breaking change.