feat:base setup for donation backend service - #11
Conversation
WalkthroughThis change introduces foundational components for the donation contribution service. It adds a TypeORM entity for campaigns, TypeScript DTOs for API responses, and a Zod validation schema for donation creation input. These additions establish the structure for handling campaign data, validating donation requests, and standardizing API responses. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Validation
participant Service
participant Database
Client->>Validation: Submit donation creation input
Validation->>Validation: Validate input with createDonationSchema
alt Validation passes
Validation->>Service: Pass validated input
Service->>Database: Create CampaignEntity
Database-->>Service: Persisted entity
Service->>Client: Return ApiResponse<CampaignResponseDto>
else Validation fails
Validation->>Client: Return ApiResponse<null> with error message
end
Estimated code review effort2 (~15 minutes) Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm error Exit handler never called! ✨ 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 (
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (7)
src/components/v1/Donation/donation.validation.ts (2)
3-3: Remove unused import.The
ValidationErrorimport appears to be unused in this file.-import { ValidationError } from "./path-to-validation-error" // reuse if needed
5-6: Validate regex patterns for security and correctness.The regex patterns look correct, but consider these improvements:
- The Ethereum address regex correctly validates the format
- The decimal string regex allows integers and decimals but doesn't prevent leading zeros or excessive decimal places
Consider making the decimal regex more restrictive to prevent edge cases:
-const decimalStringRegex = /^\d+(\.\d+)?$/ +const decimalStringRegex = /^(?:0|[1-9]\d*)(?:\.\d{1,18})?$/This prevents leading zeros and limits decimal places to 18 (typical for Ethereum tokens).
src/components/v1/Donation/donation.dto.ts (1)
10-14: Consider enhancing the generic ApiResponse interface.The current design is functional but could be enhanced for better error handling and API consistency.
Consider this enhanced version:
-export interface ApiResponse<T> { - data: T | null - success: boolean - message?: string -} +export interface ApiResponse<T> { + data: T | null + success: boolean + message?: string + error?: { + code: string + details?: string + } + timestamp?: string +}This provides better error context and API traceability.
src/components/v1/Donation/donation.entity.ts (4)
12-13: Consider using UUID type for primary key.Using
texttype for UUID primary key works but isn't optimal for performance and storage.- @PrimaryColumn("text", { name: "campaign_id" }) + @PrimaryColumn("uuid", { name: "campaign_id" })This requires ensuring your database supports UUID type and the uuid utility generates valid UUIDs.
18-19: Consider using numeric types for amounts and addresses.Using
textfortargetAmountanddonationToken(Ethereum address) may not be optimal:
targetAmountcould usedecimalornumerictype for better precisiondonationTokenas an Ethereum address could benefit from a specific length constraint- @Column("text", { name: "target_amount", nullable: false }) + @Column("decimal", { name: "target_amount", nullable: false, precision: 78, scale: 18 }) targetAmount: string - @Column("text", { name: "donation_token", nullable: false }) + @Column("varchar", { name: "donation_token", nullable: false, length: 42 })Also applies to: 22-22
10-25: Consider adding database indexes for performance.For a donation system, you'll likely query by various fields. Consider adding indexes for better performance.
@Entity("Campaign") +@Index("idx_campaign_ref", ["campaignRef"]) +@Index("idx_donation_token", ["donationToken"]) +@Index("idx_transaction_hash", ["transactionHash"]) export class CampaignEntity {Don't forget to import
Indexfrom TypeORM.
42-42: Consider removing default export in favor of named export.The class is already exported as a named export. The default export is redundant and can cause confusion.
-export default CampaignEntity
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/components/v1/Donation/donation.dto.ts(1 hunks)src/components/v1/Donation/donation.entity.ts(1 hunks)src/components/v1/Donation/donation.validation.ts(1 hunks)
🔇 Additional comments (5)
src/components/v1/Donation/donation.validation.ts (2)
17-17: Verify transaction hash regex accuracy.The transaction hash regex enforces exactly 64 hex characters after '0x', which is correct for Ethereum transaction hashes.
19-22: Network enum verified and correctly imported
- The
Networkenum is defined insrc/types/enums.ts(lines 16–23).- It’s properly imported in
src/components/v1/Donation/donation.validation.ts(line 2).No further action required.
src/components/v1/Donation/donation.dto.ts (1)
1-8: LGTM! DTO structure aligns with entity design.The
CampaignResponseDtointerface correctly mirrors theCampaignEntitystructure, ensuring consistent data transfer between database and API responses.src/components/v1/Donation/donation.entity.ts (2)
34-39: LGTM! UUID generation logic is correct.The
@BeforeInsert()hook properly generates a UUID only ifcampaignIdis not already set, preventing overwriting existing IDs.
8-8: Confirmeduuidutility implementation
- Located in src/utils/index.ts:
export const uuid = () => randomUUID();- Leverages Node.js
crypto.randomUUID()to produce valid v4 UUIDs.No changes required.
close #10
This PR sets up the foundational components for handling donations, including the database entity (CampaignEntity), input validation via Zod, and a structured response DTO for returning donation-related data to clients.
Summary by CodeRabbit
New Features
Bug Fixes