feat: add elysiajs #2114
feat: add elysiajs #2114
Conversation
📝 WalkthroughWalkthroughA new Elysia middleware handler is introduced for integrating ZenStack's RPC API with Prisma, including error handling and schema loading. An index file re-exports the handler, and a comprehensive test suite is added to validate both RPC and REST handler behaviors using Elysia, Prisma, and Zod schemas. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant ElysiaApp
participant Middleware
participant Prisma
participant RPCApiHandler
Client->>ElysiaApp: HTTP Request (any method/path)
ElysiaApp->>Middleware: Passes request to catch-all handler
Middleware->>Prisma: getPrisma(context)
alt Prisma client unavailable
Middleware-->>Client: 500 Error (Prisma client not found)
else Path missing
Middleware-->>Client: 400 Error (Path missing)
else
Middleware->>RPCApiHandler: method, path, query, body, Prisma, metadata, schemas
RPCApiHandler-->>Middleware: { status, body }
Middleware-->>Client: Response with status and body
end
Possibly related PRs
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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: 1
🧹 Nitpick comments (2)
packages/server/src/elysia/handler.ts (1)
27-33: Add type safety when retrieving Prisma clientThe current implementation casts the Prisma client directly to
DbClientContractwithout any type checking. Consider adding runtime type verification to ensure the object has the expected shape.-const prisma = (await options.getPrisma({ request, body, set } as ElysiaContext)) as DbClientContract; +const prismaClient = await options.getPrisma({ request, body, set } as ElysiaContext); + +// Validate that we have a proper Prisma client +const prisma = prismaClient as DbClientContract; +if (!prisma || typeof prisma.$transaction !== 'function') { set.status = 500; return { message: 'unable to get prisma from request context' }; }packages/server/tests/adapter/elysia.test.ts (1)
180-183: Add test coverage for SuperJSON parsingThe
unmarshalfunction supports SuperJSON parsing, but this functionality is never tested. Consider adding tests that utilizeuseSuperJson = trueto ensure this path is covered.You could add a test case similar to the existing ones but that uses SuperJSON for serialization:
it('supports SuperJSON serialization', async () => { // Test setup with SuperJSON // ... expect(await unmarshal(r, true)).toMatchObject({ // expected structure }); });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
packages/server/package.jsonis excluded by!**/*.json
📒 Files selected for processing (3)
packages/server/src/elysia/handler.ts(1 hunks)packages/server/src/elysia/index.ts(1 hunks)packages/server/tests/adapter/elysia.test.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/server/src/elysia/handler.ts (3)
packages/server/src/types.ts (1)
AdapterBaseOptions(32-56)packages/server/src/shared.ts (1)
loadAssets(5-21)packages/runtime/src/types.ts (1)
DbClientContract(91-93)
🔇 Additional comments (9)
packages/server/src/elysia/index.ts (1)
1-1: Clean barrel file for Elysia adapter exportsThis re-export approach is clean and follows the module pattern used elsewhere in the codebase, providing a convenient entry point for consumers to import the Elysia handler.
packages/server/src/elysia/handler.ts (3)
1-6: Appropriate imports for Elysia adapter implementationAll necessary imports are correctly included, utilizing types and functionality from both Elysia and the ZenStack ecosystem.
10-15: Well-typed interface for Elysia optionsThe
ElysiaOptionsinterface properly extends the base adapter options and adds the requiredgetPrismacallback to retrieve a Prisma client from the request context.
21-24: Clean initialization in the handler factoryThe implementation correctly loads model metadata and Zod schemas using the shared
loadAssetsfunction, and sets up the default request handler when none is provided.packages/server/tests/adapter/elysia.test.ts (5)
1-12: Test setup has appropriate imports and configurationsThe imports and setup code correctly include all necessary dependencies for testing the Elysia adapter.
13-83: Comprehensive RPC handler tests cover critical pathsThe test suite for RPC handler covers all essential operations including querying, creating, updating, and deleting records, as well as more advanced functionality like filtering, aggregation, and grouping.
85-112: Custom load path test verifies schema loading flexibilityThis test correctly verifies that the adapter can load model metadata and Zod schemas from a custom output path, confirming the adapter's ability to work with various project configurations.
115-172: REST handler tests provide adequate coverageThe REST handler tests properly validate CRUD operations and filtering capabilities using the REST endpoint format.
185-189: Clean helper function for Elysia app creationThe
createElysiaApphelper function provides a clean way to set up an Elysia app with the middleware, promoting code reuse across tests.
| return async (app: Elysia) => { | ||
| app.all('/*', async ({ request, body, set }: ElysiaContext) => { | ||
| const prisma = (await options.getPrisma({ request, body, set } as ElysiaContext)) as DbClientContract; | ||
| if (!prisma) { | ||
| set.status = 500; | ||
| return { | ||
| message: 'unable to get prisma from request context' | ||
| }; | ||
| } | ||
|
|
||
| const url = new URL(request.url); | ||
| const query = Object.fromEntries(url.searchParams); | ||
| const path = url.pathname; | ||
|
|
||
| if (!path) { | ||
| set.status = 400; | ||
| return { | ||
| message: 'missing path parameter' | ||
| }; | ||
| } | ||
|
|
||
| try { | ||
| const r = await requestHandler({ | ||
| method: request.method, | ||
| path, | ||
| query, | ||
| requestBody: body, | ||
| prisma, | ||
| modelMeta, | ||
| zodSchemas, | ||
| logger: options.logger, | ||
| }); | ||
|
|
||
| set.status = r.status; | ||
| return r.body; | ||
| } catch (err) { | ||
| set.status = 500; | ||
| return { | ||
| message: `An unhandled error occurred: ${err}` | ||
| }; | ||
| } | ||
| }); | ||
|
|
||
| return app; | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider more robust error handling in the catch block
The error handling should avoid exposing raw error objects to clients, as this could potentially leak sensitive information.
} catch (err) {
set.status = 500;
return {
- message: `An unhandled error occurred: ${err}`
+ message: 'An internal server error occurred'
};
}Additionally, consider logging the actual error details for debugging purposes:
console.error('Elysia handler error:', err);
Add Elysia adapter