Choosing an SDK

Define the job first

Write down the operation your application needs and the constraints it must respect. “Search” is broad. “Find five recent source URLs with snippets from an approved set of domains” gives you something concrete to evaluate.

• Runtime: browser, Node.js server, edge runtime, mobile, or a background worker?
• Data: what will leave your system, and where may it be processed?
• Behavior: streaming, pagination, transactions, cancellation, or idempotency?
• Operations: expected volume, response deadline, budget, and failure tolerance?

Evaluate the library

Run a small integration spike

1. Install the official package in a throwaway branch or isolated example.
2. Make one happy-path call with realistic input.
3. Trigger one validation error and one controlled timeout.
4. Record the useful result, native error details, and any missing capabilities.
5. Run it in the actual target runtime before committing to the dependency.

For an email integration, the Resend official Node.js repository and sending reference are useful primary sources. Follow the same source trail for every provider you evaluate.

Decide what to wrap

Start with the native client. Extract a narrow application boundary when your product has a stable operation to name. Keep provider-specific options close to the integration, and avoid designing a universal interface before you have a second real use case.

type ReceiptEmail = {
  orderId: string;
  recipient: string;
};

// Your product operation, not a universal email API.
export interface ReceiptSender {
  sendReceipt(input: ReceiptEmail): Promise<{
    messageId: string;
    provider: string;
  }>;
}