feat(client, server): batch request/response plugin#329
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis pull request introduces a Batch Request/Response feature across multiple parts of the system. It adds new documentation and sidebar entries, enhances client-side functionality with a Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant BL as BatchLinkPlugin
participant N as Network
participant BH as BatchHandlerPlugin
participant S as Server
C->>BL: Initiate individual requests
BL->>BL: Enqueue & group requests for batching
BL->>N: Dispatch batched request
N->>BH: Forward batched request
BH->>S: Process each batched request
S-->>BH: Return individual responses
BH-->>N: Assemble batch response
N-->>BL: Deliver batch response
BL->>C: Resolve individual request promises
Possibly related PRs
Poem
🪧 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 (
|
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/openapi
@orpc/contract
@orpc/openapi-client
@orpc/react
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/svelte-query
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (10)
playgrounds/nextjs/src/lib/orpc.ts (1)
13-20:Details
❓ Verification inconclusive
Consider refining the batch condition logic for more targeted batching.
The current implementation batches all eligible requests together since the condition always returns
true. While this works, consider if more specific batching groups would be more appropriate for your use case.You could refine the batching strategy by grouping related requests together:
- new BatchLinkPlugin({ - groups: [{ - condition: () => true, - context: {}, - }], - }), + new BatchLinkPlugin({ + groups: [ + { + // Group read operations + condition: (options) => ['GET', 'HEAD'].includes(options.request.method), + context: {}, + }, + { + // Group write operations + condition: (options) => ['POST', 'PUT', 'PATCH'].includes(options.request.method), + context: {}, + } + ], + }),Let's verify what types of requests are typically made in the application to determine if targeted batching would be beneficial:
🏁 Script executed:
#!/bin/bash # Find all RPC method calls to understand the request patterns rg "orpcClient\." --type ts -A 2 -B 2Length of output: 39
Targeted Batching for BatchLinkPlugin
The current implementation in
playgrounds/nextjs/src/lib/orpc.tsuses an unconditional batching strategy (condition: () => true), which groups all requests together. The proposed diff suggests splitting the batching logic into separate groups for read operations (e.g.,GET,HEAD) and write operations (e.g.,POST,PUT,PATCH), which could improve efficiency if the request patterns warrant such separation.- new BatchLinkPlugin({ - groups: [{ - condition: () => true, - context: {}, - }], - }), + new BatchLinkPlugin({ + groups: [ + { + // Group read operations + condition: (options) => ['GET', 'HEAD'].includes(options.request.method), + context: {}, + }, + { + // Group write operations + condition: (options) => ['POST', 'PUT', 'PATCH'].includes(options.request.method), + context: {}, + } + ], + }),However, our search for typical RPC method usage (via
rg "orpcClient.") did not yield any results, so the evidence for distinct request patterns is inconclusive. Please manually verify the request patterns in the application to ensure that differentiating between read and write operations is beneficial. If the codebase does distinguish request types, the refined strategy could lead to improved batching; otherwise, the existing unconditional approach may suffice.packages/standard-server/src/batch/request.test.ts (2)
21-57: Consider testing an empty requests array scenario.The “method GET” test covers typical usage. You might also verify behavior when the
requestsarray is empty (i.e., no sub-requests). This ensures thatparseBatchRequestcan handle edge cases gracefully.
59-95: Extend tests to cover additional edge cases.Similarly, for the “method POST” test, consider adding a scenario with zero sub-requests to confirm expected handling of empty arrays.
packages/standard-server/src/batch/signal.ts (1)
6-20: Revisit the all-or-nothing abort logic.Currently, the controller aborts only if all provided signals are aborted. If the intended behavior is to halt as soon as one signal aborts, consider short-circuiting on the first abort for improved responsiveness. Otherwise, confirm that the all-or-nothing approach is desired.
packages/shared/src/array.ts (1)
1-3: Refine the type assertion for stronger type safety.The
as anyassertion can mask potential type mismatches. Consider removing or narrowing the assertion to ensure stricter type checks, unless you rely on broad flexibility.packages/server/src/plugins/batch.ts (1)
60-149: Large async logic block ininitcould benefit from modularization.
While the current logic is comprehensive — parsing requests, verifying batch size, dispatching sub-requests, and assembling a streaming response — it’s quite lengthy. Consider extracting chunks of logic (e.g., batch-size checking, request dispatch, response streaming) into helper functions or internal methods. This refactor could improve readability, maintainability, and reusability.packages/standard-server/src/batch/response.ts (1)
12-14: Consider adding a clarifying comment.While the implementation is correct, the
toBatchResponsefunction is just a pass-through that returns the input options. Adding a comment explaining the purpose of this function would improve code readability.export function toBatchResponse(options: ToBatchResponseOptions): StandardResponse { + // This function serves as a type converter and API consistency marker + // It makes the API more explicit and allows for future extension return options }apps/content/docs/plugins/batch-request-response.md (2)
60-60: Add a hyphen or clarify “auto-fall back.”“Requests will auto fall back” may be unclear or grammatically incorrect. For better clarity and style, consider adding a hyphen or rephrasing:
- The plugin does not support [AsyncIteratorObject](...) in responses (requests will auto fall back to the default behavior). + The plugin does not support [AsyncIteratorObject](...) in responses (requests will auto-fall back to the default behavior).🧰 Tools
🪛 LanguageTool
[uncategorized] ~60-~60: It appears that a hyphen is missing (if ‘auto’ is not used in the context of ‘cars’).
Context: ...data-types) in responses (requests will auto fall back to the default behavior). To exclu...(AUTO_HYPHEN)
112-112: Fix subject-verb agreement.“headers” is plural, so the phrase should read “response headers are empty.” Suggest updating the text:
- By default, the response headers is empty. + By default, the response headers are empty.🧰 Tools
🪛 LanguageTool
[grammar] ~112-~112: The verb form ‘is’ does not seem to match the subject ‘headers’.
Context: ...aders By default, the response headers is empty. To customize headers, use the `h...(SUBJECT_VERB_AGREEMENT_PLURAL)
packages/client/src/plugins/batch.ts (1)
125-139: Consider removing the header instead of setting it toundefined.Setting
'x-orpc-batch': undefinedmay keep the header key in some client libraries, which can cause unexpected behavior. Consider deleting it explicitly when not needed:- 'x-orpc-batch': undefined, + // Remove the batch header altogether: + ...Object.fromEntries(Object.entries(options.request.headers).filter(([k]) => k !== 'x-orpc-batch')),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
apps/content/.vitepress/config.ts(1 hunks)apps/content/docs/comparison.md(1 hunks)apps/content/docs/plugins/batch-request-response.md(1 hunks)packages/client/src/plugins/batch.test.ts(1 hunks)packages/client/src/plugins/batch.ts(1 hunks)packages/client/src/plugins/index.ts(1 hunks)packages/server/src/plugins/batch.test.ts(1 hunks)packages/server/src/plugins/batch.ts(1 hunks)packages/server/src/plugins/index.ts(1 hunks)packages/shared/src/array.test.ts(1 hunks)packages/shared/src/array.ts(1 hunks)packages/standard-server/package.json(1 hunks)packages/standard-server/src/batch/index.ts(1 hunks)packages/standard-server/src/batch/request.test.ts(1 hunks)packages/standard-server/src/batch/request.ts(1 hunks)packages/standard-server/src/batch/response.test.ts(1 hunks)packages/standard-server/src/batch/response.ts(1 hunks)packages/standard-server/src/batch/signal.test.ts(1 hunks)packages/standard-server/src/batch/signal.ts(1 hunks)playgrounds/nextjs/src/app/rpc/[[...rest]]/route.ts(1 hunks)playgrounds/nextjs/src/lib/orpc.ts(1 hunks)
🧰 Additional context used
🧬 Code Definitions (9)
packages/standard-server/src/batch/signal.test.ts (1)
packages/standard-server/src/batch/signal.ts (1)
toBatchAbortSignal(1-23)
packages/server/src/plugins/batch.ts (5)
packages/server/src/context.ts (1)
Context(1-1)packages/shared/src/value.ts (2)
Value(3-3)value(5-14)packages/standard-server/src/types.ts (2)
StandardRequest(13-24)StandardHeaders(1-3)packages/standard-server/src/batch/response.ts (2)
BatchResponseBodyItem(4-6)toBatchResponse(12-14)packages/standard-server/src/batch/request.ts (1)
parseBatchRequest(40-58)
packages/client/src/plugins/batch.test.ts (5)
packages/standard-server/src/batch/response.ts (1)
toBatchResponse(12-14)packages/client/src/adapters/standard/link.ts (2)
path(53-65)StandardLink(28-66)packages/standard-server/src/types.ts (1)
StandardRequest(13-24)packages/client/src/plugins/batch.ts (2)
BatchLinkPlugin(61-269)method(193-268)packages/shared/src/iterator.ts (1)
isAsyncIteratorObject(1-7)
playgrounds/nextjs/src/lib/orpc.ts (2)
packages/client/src/adapters/fetch/rpc-link.ts (1)
RPCLink(10-19)packages/client/src/plugins/batch.ts (1)
BatchLinkPlugin(61-269)
playgrounds/nextjs/src/app/rpc/[[...rest]]/route.ts (1)
packages/server/src/plugins/batch.ts (1)
BatchHandlerPlugin(39-150)
packages/standard-server/src/batch/response.ts (3)
packages/standard-server/src/types.ts (1)
StandardResponse(34-41)packages/shared/src/iterator.ts (1)
isAsyncIteratorObject(1-7)packages/shared/src/object.ts (1)
isObject(31-39)
packages/server/src/plugins/batch.test.ts (4)
packages/server/src/plugins/batch.ts (1)
BatchHandlerPlugin(39-150)packages/standard-server/src/types.ts (2)
StandardRequest(13-24)StandardLazyRequest(26-32)packages/standard-server/src/batch/request.ts (1)
toBatchRequest(12-38)packages/standard-server/src/batch/response.ts (1)
parseBatchResponse(16-41)
packages/standard-server/src/batch/request.ts (3)
packages/standard-server/src/types.ts (2)
StandardHeaders(1-3)StandardRequest(13-24)packages/shared/src/json.ts (2)
stringifyJSON(9-12)parseEmptyableJSON(1-7)packages/standard-server/src/batch/signal.ts (1)
toBatchAbortSignal(1-23)
packages/client/src/plugins/batch.ts (8)
packages/client/src/adapters/standard/link.ts (3)
StandardLinkClientInterceptorOptions(18-20)StandardLinkPlugin(9-11)StandardLinkOptions(22-26)packages/shared/src/value.ts (2)
Value(3-3)value(5-14)packages/standard-server/src/types.ts (3)
StandardHeaders(1-3)StandardRequest(13-24)StandardLazyResponse(43-49)packages/shared/src/interceptor.ts (1)
InterceptorOptions(6-12)packages/shared/src/iterator.ts (1)
isAsyncIteratorObject(1-7)packages/shared/src/array.ts (2)
splitInHalf(5-8)toArray(1-3)packages/standard-server/src/batch/request.ts (1)
toBatchRequest(12-38)packages/standard-server/src/batch/response.ts (1)
parseBatchResponse(16-41)
🪛 LanguageTool
apps/content/docs/plugins/batch-request-response.md
[uncategorized] ~60-~60: It appears that a hyphen is missing (if ‘auto’ is not used in the context of ‘cars’).
Context: ...data-types) in responses (requests will auto fall back to the default behavior). To exclu...
(AUTO_HYPHEN)
[grammar] ~112-~112: The verb form ‘is’ does not seem to match the subject ‘headers’.
Context: ...aders By default, the response headers is empty. To customize headers, use the `h...
(SUBJECT_VERB_AGREEMENT_PLURAL)
🔇 Additional comments (38)
packages/server/src/plugins/index.ts (1)
1-1: Export changes look correctThis addition properly exports the batch plugin module, following the consistent pattern used for other plugin exports in this file.
packages/client/src/plugins/index.ts (1)
1-1: Export looks goodThe batch plugin export follows the same pattern as the existing retry plugin export, maintaining consistency in the module structure.
apps/content/.vitepress/config.ts (1)
112-112: Documentation entry added appropriatelyThe new sidebar entry for Batch Request/Response is correctly placed in the Plugins section and follows the same format as other plugin entries.
apps/content/docs/comparison.md (1)
36-36: Feature status updated accuratelyThe status for Batch Request has been correctly updated to indicate first-class built-in support in oRPC, which aligns with the implementation of the new batch functionality.
packages/standard-server/src/batch/index.ts (1)
1-3: LGTM! Clean and concise index file export.This file serves as a well-organized entry point for batch functionality, making it easy to import all batch-related features from a single location.
playgrounds/nextjs/src/app/rpc/[[...rest]]/route.ts (2)
5-5: LGTM! Good addition of the BatchHandlerPlugin import.Clean import statement for the new batch handling functionality.
13-15:Details
✅ Verification successful
BatchHandlerPlugin integration looks good, consider documenting default settings.
The BatchHandlerPlugin is correctly integrated into the RPCHandler, enabling batch request processing on the server side. The plugin is using default configuration settings (maxSize: 10, successStatus: 207).
If you anticipate higher batch volumes, you might want to consider customizing the maxSize:
🏁 Script executed:
#!/bin/bash # Search for any existing batch size limits or configuration patterns in the codebase rg -A 5 -B 5 "new BatchHandlerPlugin\(" --type tsLength of output: 5119
BatchHandlerPlugin integration verified; consider clarifying default settings in documentation
The integration in
playgrounds/nextjs/src/app/rpc/[[...rest]]/route.tscorrectly instantiates the plugin using its default configuration (implicitly usingmaxSize: 10andsuccessStatus: 207). This aligns with the setup seen in test files (e.g.,packages/server/src/plugins/batch.test.tsandpackages/client/src/plugins/batch.test.ts), where both default and customized configurations (such as{ maxSize: 2 }) are demonstrated.For improved clarity and maintainability, please consider adding inline documentation or updating your project docs to clearly state these default values. This will help future developers understand the behavior of the BatchHandlerPlugin—especially if adjustments are needed when handling higher batch volumes.
packages/shared/src/array.test.ts (2)
1-1: LGTM! Import looks good.Correctly importing both the existing
toArrayand newsplitInHalffunctions.
10-17: Test cases for splitInHalf are comprehensive and well-structured.The test suite covers all essential scenarios, including:
- Arrays with odd/even number of elements
- Edge cases (arrays with 1 element and empty arrays)
- The behavior is consistent with what would be expected from a function named
splitInHalfplaygrounds/nextjs/src/lib/orpc.ts (1)
6-6: LGTM! Good addition of the BatchLinkPlugin import.Clean import statement for the client-side batch functionality.
packages/standard-server/src/batch/request.test.ts (2)
1-9: Looks good overall.Imports, mocks, and initial setup are clear and concise. Test isolation via
vi.clearAllMocks()is correctly implemented.
98-116: Comprehensive negative test coverage.The invalid batch request checks (missing body, wrong method, etc.) are well-handled, ensuring robust error handling.
packages/shared/src/array.ts (1)
5-8: Neat approach to splitting arrays.Using
Math.ceil()ensures the first half includes any leftover element when array length is odd. This function is straightforward and seems correct.packages/standard-server/package.json (2)
21-25: New batch export entries look consistent.
All paths for types, import, and default appear correct and match the newly addedbatchmodule structure.
30-31: New public export path for./batchis aligned with the source structure.
These lines correctly reference./src/batch/index.tsfor the new batch functionality.packages/standard-server/src/batch/signal.test.ts (3)
3-20: Excellent coverage for partially aborted signals.
The test scenarios (empty array, undefined, partially aborted signals) thoroughly validate that the returned signal is not aborted when not all inputs are aborted. Keep it up!
22-30: Validates the scenario where all input signals are already aborted.
This test confirms that the returned signal is immediately aborted if all signals were aborted beforehand. Great job on ensuring edge-case coverage.
32-58: Abort event handling is well-tested.
Verifies that the abort event is fired only after the last non-aborted signal is aborted. The usage ofvi.fn()is appropriate for spying on the event listener.packages/server/src/plugins/batch.ts (2)
9-37: Extensive and flexibleBatchHandlerOptionsinterface.
The documentation (e.g.,@defaulttags) for each property is well-written, and the optional fields with reasonable defaults demonstrate good design.
39-58: Constructor defaults are aptly handled.
Using??operators to supply fallback values formaxSize,mapRequestItem,successStatus, andheadersensures robust handling, reducing risk of undefined behavior.packages/standard-server/src/batch/response.test.ts (2)
5-30: Test suite looks thorough and well-structured.The test cases effectively validate both
toBatchResponseandparseBatchResponsefunctions, checking for correct status codes, headers, and ensuring the async iterator properly yields the expected batch response items.
32-54: Good error handling tests.These tests properly verify that
parseBatchResponsethrows the appropriate errors for invalid inputs, checking both non-iterable bodies and malformed batch items.packages/standard-server/src/batch/response.ts (1)
16-41: Implementation looks solid.The
parseBatchResponsefunction properly validates that the response body is an async iterator and that each item has the required properties. The use of afinallyblock to clean up resources by callingbody.return?()is a good practice.packages/client/src/plugins/batch.test.ts (6)
21-136: Well-structured batch plugin tests.The tests thoroughly verify that the
BatchLinkPlugincorrectly batches multiple requests into a single batch request, properly handles response parsing, and maintains correct context and signal propagation.
138-201: Good coverage of edge cases.These tests properly verify that the plugin:
- Doesn't batch unsupported body types like FormData and AsyncIterator
- Processes requests individually when no matching group is found
- Maintains proper request isolation and context
This ensures the batching mechanism only activates when appropriate.
203-219: Error handling correctly tested.Tests verify that invalid batch responses properly propagate errors to all batched requests, ensuring failures are handled gracefully.
221-291: Comprehensive batching logic tests.These tests verify important batching features:
- Correct separation of GET and non-GET requests
- Splitting batches that exceed maximum size
- Handling URL length limitations
These scenarios are critical for real-world use cases with varying request types and volumes.
293-359: Good testing of additional features.Tests verify that:
- The
x-orpc-batchheader is properly handled- Exclusion rules work correctly
- Error handling for missing responses is appropriate
These edge cases ensure the batching mechanism is robust.
362-421: Integration testing looks good.Testing the integration between
BatchLinkPluginandBatchHandlerPluginis important to ensure end-to-end functionality works correctly. Both success and error scenarios are verified.packages/server/src/plugins/batch.test.ts (6)
10-166: Comprehensive batch handler tests.The tests thoroughly verify:
- Correct handling of batch requests
- Proper response status and headers
- Response parsing and validation
- Handling of concurrent requests with varying response times
The temporal tests (with varying sleep times) validate that responses are yielded in the order they complete rather than the order they were submitted, which is important for async behavior.
168-220: Good coverage of customization options.Tests validate that custom success status, headers, and request mapping options work correctly, ensuring the plugin is flexible enough for various use cases.
222-256: Error handling tests look good.These tests verify that non-batch requests are ignored and invalid batch requests result in appropriate error responses rather than exceptions.
258-283: Error propagation test is important.Verifying that unknown errors are properly propagated ensures that developer errors aren't silently caught by the batch handler.
285-416: Good validation of error handling strategy.Tests verify that request errors result in appropriate error responses in the batch rather than failing the entire batch. This is an important resilience feature of batch processing.
418-448: Size limit enforcement test is important.Validating that batch size limits are enforced helps prevent potential DoS vulnerabilities from oversized batch requests.
packages/standard-server/src/batch/request.ts (2)
12-22: Validate URL property of each sub-request.Although the code maps each sub-request item into
{ method, url, headers, body }, there's no check thaturlis a valid URL string. If a user-provided sub-request item has an invalid URL, thenew URL(item.url)call inparseBatchRequest(lines 52-52) will throw aTypeErrorat runtime. Consider validating or catching potential parsing errors.
31-38: Double-check merged signals for concurrency.
toBatchAbortSignalmerges multiple abort signals so that if any sub-request is aborted, the entire batch is aborted. Confirm that this is the intended behavior. If you only want to abort the rest of the operations but continue others independently, a different approach might be required.packages/client/src/plugins/batch.ts (1)
143-149: Watch for unsupported request bodies in the batch.The plugin excludes requests if the body is a
Blob,FormData, or an async iterator, but other unsupported binary or streaming formats might cause failures. Verify that these are indeed the only formats you need to exclude or handle specially.
| export function parseBatchRequest(request: StandardRequest): StandardRequest[] { | ||
| const items = request.method === 'GET' | ||
| ? parseEmptyableJSON(request.url.searchParams.getAll('batch').at(-1)) | ||
| : request.body | ||
|
|
||
| if (!Array.isArray(items)) { | ||
| throw new TypeError('Invalid batch request') | ||
| } | ||
|
|
||
| return items.map((item) => { | ||
| return { | ||
| method: item.method, | ||
| url: new URL(item.url), | ||
| headers: item.headers, | ||
| body: item.body, | ||
| signal: request.signal, | ||
| } satisfies StandardRequest | ||
| }) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add defensive checks for request fields.
parseBatchRequest reconstructs StandardRequest objects from untrusted sources, relying on Array.isArray(items) alone. Consider additional validation on each property (e.g., method, headers) to avoid malformed requests from leading to unexpected behavior at runtime.
| for await (const item of parsed) { | ||
| batchItems[item.index]?.[1]({ ...item, body: () => Promise.resolve(item.body) }) | ||
| } | ||
|
|
||
| /** | ||
| * JS ignore the second resolve or reject so we don't need to check if has been resolved | ||
| */ | ||
| throw new Error('Something went wrong make batch response not contains enough responses. This can be a bug please report it.') | ||
| } |
There was a problem hiding this comment.
Prevent unconditional error throw after successful batch handling.
Currently, the code always throws an error after yielding the responses, even if all items were successfully resolved. Add a condition to check for mismatched responses or return early when everything is handled:
yield item as unknown as BatchResponseBodyItem
}
}
finally {
await body.return?.()
}
+ // Return early if all items were processed
+ if (batchItems.length === parsedItemCount) {
+ return
+ }
throw new Error('Something went wrong...')Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
apps/content/docs/plugins/batch-request-response.md (3)
14-17: Setup Section Provides Essential OverviewThe setup section explains the need for configurations on both the client and server sides. Consider adding a reference link or note that elaborates on the configuration steps if further details are available in the documentation elsewhere.
20-29: Effective Server-Side Code ExampleThe server code snippet clearly demonstrates how to integrate the
BatchHandlerPluginwith an RPC handler. However, the use of the// ---cut---marker might confuse new users. Consider adding a brief explanation (either as a comment or in the adjacent text) that this marker indicates omitted code for brevity.
58-60: Limitations Section – Consider Rephrasing for ClarityThe explanation on limitations is clear; however, the phrase "requests will auto fall back to the default behavior" could be improved for clarity. For example, consider rephrasing to "requests will automatically fall back to the default behavior."
Proposed diff:
- in responses (requests will auto fall back to the default behavior). + in responses (requests will automatically fall back to the default behavior).🧰 Tools
🪛 LanguageTool
[uncategorized] ~60-~60: It appears that a hyphen is missing (if ‘auto’ is not used in the context of ‘cars’).
Context: ...data-types) in responses (requests will auto fall back to the default behavior). To exclu...(AUTO_HYPHEN)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/content/docs/plugins/batch-request-response.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
apps/content/docs/plugins/batch-request-response.md
[uncategorized] ~60-~60: It appears that a hyphen is missing (if ‘auto’ is not used in the context of ‘cars’).
Context: ...data-types) in responses (requests will auto fall back to the default behavior). To exclu...
(AUTO_HYPHEN)
🔇 Additional comments (9)
apps/content/docs/plugins/batch-request-response.md (9)
1-4: Front Matter Metadata Looks SolidThe front matter is clean and clearly specifies the title and description for the plugin documentation. Verify that these metadata fields align with the overall documentation standards.
6-9: Clear Plugin IntroductionThe introductory header and description succinctly state the purpose of the Batch Request/Response Plugin. The language is straightforward and informative.
10-12: Well-Formatted Info BlockThe info block clearly communicates that the plugin streams responses asynchronously to prevent blocking. This helps set the right expectations for the reader.
31-33: Comprehensive Handler ContextThe info block following the server example effectively describes the possible handler types and notes the custom protocol used by the plugin. This additional context is helpful.
35-38: Client-Side Overview is ClearThe brief description before the client code example provides a good overview of what is expected when using the
BatchLinkPlugin.
39-56: Solid Client-Side Code ExampleThe client example precisely demonstrates how to configure the
BatchLinkPluginby defining groups and contexts. The example is easy to follow and clearly formatted.
62-82: Good Example for Excluding Unsupported ProceduresThe code snippet using the
excludeoption demonstrates clearly how to filter out procedures that return unsupported types. The example is concise and well-commented.
84-108: Request Headers Customization is Clearly DocumentedThe section on Request Headers provides a straightforward example of how to customize headers for batched requests. The configuration shown is concise and appropriate.
110-127: Response Headers Example is InformativeThe Response Headers section offers a clear demonstration of how to customize headers on the server side via the
BatchHandlerPlugin. The example and accompanying explanation are well structured.
1 participant
Summary by CodeRabbit
New Features
Documentation
Tests