https://github.com/vintasoftware/vintasend-ts
A flexible package for implementing transactional notifications
https://github.com/vintasoftware/vintasend-ts
Last synced: 4 months ago
JSON representation
A flexible package for implementing transactional notifications
- Host: GitHub
- URL: https://github.com/vintasoftware/vintasend-ts
- Owner: vintasoftware
- License: mit
- Created: 2025-02-12T05:24:20.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2026-03-03T18:19:16.000Z (4 months ago)
- Last Synced: 2026-03-03T21:59:33.928Z (4 months ago)
- Language: TypeScript
- Size: 741 KB
- Stars: 8
- Watchers: 4
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# VintaSend TypeScript
A flexible package for implementing transactional notifications in TypeScript.
## Features
* **Storing notifications in a Database**: This package relies on a data store to record all the notifications that will be sent. It also keeps its state column up to date.
* **One-off notifications**: Send notifications directly to email addresses or phone numbers without requiring a user account. Perfect for prospects, guests, or external contacts.
* **File Attachments**: Attach files to notifications with flexible storage backend support (S3, Azure, GCS, local filesystem, etc.), automatic deduplication, and reusable file references.
* **Scheduling notifications**: Storing notifications to be sent in the future. The notification's context for rendering the template is only evaluated at the moment the notification is sent due to the lib's context generation registry.
* **Notification context fetched at send time**: On scheduled notifications, the package only gets the notification context (information to render the templates) at the send time, so we always get the most up-to-date information.
* **Flexible backend**: Your project's database is getting slow after you created the first million notifications? You can migrate to a faster NoSQL database in the blink of an eye without affecting how you send the notifications.
* **Flexible adapters**: Your project probably will need to change how it sends notifications over time. This package allows you to change the adapter without having to change how notification templates are rendered or how the notification themselves are stored.
* **Flexible template renderers**: Wanna start managing your templates with a third party tool (so non-technical people can help maintain them)? Or even choose a more powerful rendering engine? You can do it independently of how you send the notifications or store them in the database.
* **Sending notifications in background jobs**: This package supports using job queues to send notifications from separate processes. This may be helpful to free up the HTTP server of processing heavy notifications during the request time.
## How does it work?
The VintaSend package provides a NotificationService class that allows the user to store and send notifications, scheduled or not. It relies on Dependency Injection to define how to store/retrieve, render the notification templates, and send notifications. This architecture allows us to swap each part without changing the code we actually use to send the notifications.
### Scheduled Notifications
VintaSend schedules notifications by creating them on the database for sending when the `sendAfter` value has passed. The sending isn't done automatically but we have a service method called `sendPendingNotifications` to send all pending notifications found in the database.
You need to call the `sendPendingNotifications` service method in a cron job or a tool for running periodic jobs.
#### Keeping the content up-to-date in scheduled notifications
The VintaSend class stores every notification in a database. This helps us to audit and manage our notifications. At the same time, notifications usually have a context that's used to hydrate its template with data. If we stored the context directly on the notification records, we'd have to update it anytime the context changes.
## Installation
```bash
npm install vintasend
# or
yarn add vintasend
```
## Getting Started
To start using VintaSend you just need to initialize the notification service and start using it to manage your notifications.
```typescript
import { VintaSendFactory } from 'vintasend';
import type { ContextGenerator } from 'vintasend';
// context generator for Welcome notification
class WelcomeContextGenerator extends ContextGenerator {
async generate ({ userId }: { userId: number }): { firstName: string } {
const user = await getUserById(userId); // example
return {
firstName: user.firstName,
};
}
}
// context map for generating the context of each notification
export const contextGeneratorsMap = {
welcome: new WelcomeContextGenerator(),
} as const;
// type config definition, so all modules use the same types
export type NotificationTypeConfig = {
ContextMap: typeof contextGeneratorsMap;
NotificationIdType: number;
UserIdType: number;
};
export function getNotificationService() {
/*
Function to instanciate the notificationService
The Backend, Template Renderer, Logger, and Adapter used here are not included
here and should be installed and imported separately or manually defined if
the existing implementations don't support the specific use-case.
*/
const backend = new MyNotificationBackendFactory().create();
const templateRenderer = new MyNotificationAdapterFactory().create();
const adapter = new MyNotificationAdapterFactory().create(
templateRenderer, true
);
return new VintaSendFactory().create(
[adapter],
backend,
new MyLogger(loggerOptions),
contextGeneratorsMap,
);
}
export function sendWelcomeEmail(userId: number) {
/* sends the Welcome email to a user */
const vintasend = getNotificationService();
const now = new Date();
vintasend.createNotification({
userId: user.id,
notificationType: 'EMAIL',
title: 'Welcome Email',
contextName: 'welcome',
contextParameters: { userId },
sendAfter: now,
bodyTemplate: './src/email-templates/auth/welcome/welcome-body.html.template',
subjectTemplate: './src/email-templates/auth/welcome/welcome-subject.txt.template',
extraParams: {},
});
}
```
## Multi-Backend Configuration
VintaSend supports configuring multiple backends for redundancy, data distribution, and migration use cases.
### Basic Setup
```typescript
import { VintaSendFactory } from 'vintasend';
const vintasend = new VintaSendFactory().create({
adapters,
backend: primaryBackend,
additionalBackends: [replicaBackend],
logger,
contextGeneratorsMap,
});
```
### How It Works
- **Writes**: VintaSend writes to the primary backend first, then replicates to additional backends either inline (default) or through a per-backend replication queue.
- **Reads**: Read methods use the primary backend by default, but support optional backend targeting by identifier.
```typescript
// Read from primary backend (default)
const notification = await vintasend.getNotification(notificationId);
// Read from a specific backend
const notificationFromReplica = await vintasend.getNotification(
notificationId,
false,
'replica-backend',
);
```
### Backend Management Operations
```typescript
const report = await vintasend.verifyNotificationSync(notificationId);
if (!report.synced) {
await vintasend.replicateNotification(notificationId);
}
const backendStats = await vintasend.getBackendSyncStats();
```
### Asynchronous Replication Queue (Per Backend)
VintaSend supports asynchronous replication to additional backends with one queued task per destination backend.
#### Replication mode
Use `replicationMode: 'queued'` to enqueue replication instead of replicating inline in the request path.
```typescript
const vintasend = new VintaSendFactory().create({
adapters,
backend: primaryBackend,
additionalBackends: [replicaA, replicaB],
logger,
contextGeneratorsMap,
replicationQueueService,
options: {
raiseErrorOnFailedSend: false,
replicationMode: 'queued',
},
});
```
#### Replication queue contract
The replication queue service receives both the notification id and the target backend identifier:
```typescript
export interface BaseNotificationReplicationQueueService {
enqueueReplication(notificationId: Config['NotificationIdType'], backendIdentifier: string): Promise;
}
```
When queued replication is enabled, VintaSend enqueues one replication task for each additional backend.
#### Worker processing
Workers should process replication with a backend target to apply replication only for the queued destination:
```typescript
await vintasend.processReplication(notificationId, backendIdentifier);
```
You can still call `processReplication(notificationId)` without a target to process all additional backends.
#### Ordering and idempotency safety
To reduce out-of-order replication issues, backends can optionally implement conditional apply:
```typescript
applyReplicationSnapshotIfNewer?(snapshot): Promise<{ applied: boolean }>;
```
- If destination state is newer/equal, replication is skipped (`applied: false`).
- If destination is older, snapshot is applied.
- Duplicate-create race conditions are handled with create→update fallback in worker replication flow.
Official backends `vintasend-prisma` and `vintasend-medplum` implement this conditional apply behavior.
### Failure Handling
- Primary backend failures fail the operation.
- Additional backend replication failures are logged and do not fail the primary operation.
- In queued mode, enqueue failures fall back to inline replication for affected backends.
- This keeps primary workflows available while still enabling redundancy and eventual consistency.
## Filtering and Ordering Notifications
Use `filterNotifications` to query notifications with pagination and optional ordering.
```typescript
const notifications = await vintasend.filterNotifications(
{
status: 'PENDING_SEND',
},
1,
25,
{
field: 'createdAt',
direction: 'desc',
},
);
```
### `orderBy` shape
```typescript
type NotificationOrderBy = {
field: 'sendAfter' | 'sentAt' | 'readAt' | 'createdAt' | 'updatedAt';
direction: 'asc' | 'desc';
};
```
Examples:
- `{ field: 'createdAt', direction: 'desc' }`
- `{ field: 'sendAfter', direction: 'asc' }`
### Checking backend support
Use `getBackendSupportedFilterCapabilities()` to detect support gaps per backend.
```typescript
const capabilities = await vintasend.getBackendSupportedFilterCapabilities();
if (!capabilities['orderBy.readAt']) {
// Fallback to another ordering field
}
```
When using multiple backends, you can check capabilities for a specific backend identifier:
```typescript
const replicaCapabilities = await vintasend.getBackendSupportedFilterCapabilities('replica-backend');
```
`vintasend-medplum` currently does not support `orderBy.readAt`, and reports `orderBy.readAt: false`.
## Attachment Support
VintaSend supports file attachments for notifications with an extensible architecture that allows you to choose your preferred storage backend.
### Key Features
- ✅ **Flexible Storage** - Support for multiple backends (AWS S3, Azure Blob, Google Cloud Storage, local filesystem, etc.)
- ✅ **Reusable Files** - Upload once, attach to multiple notifications
- ✅ **Automatic Deduplication** - Files with identical content stored only once
- ✅ **Streaming Support** - Efficient handling of large files
- ✅ **Presigned URLs** - Secure, time-limited file access (backend-dependent)
- ✅ **Custom Backends** - Extensible interface to implement any storage service
### Quick Start
```typescript
// Example using S3 AttachmentManager (see available implementations below)
import { S3AttachmentManager } from 'vintasend-aws-s3-attachments';
// Create attachment manager (configuration varies by implementation)
const attachmentManager = new S3AttachmentManager({
bucket: 'my-app-notifications',
region: 'us-east-1',
keyPrefix: 'attachments/',
});
// Create VintaSend with attachment support
const vintaSend = factory.create(
adapters,
backend,
templateRenderer,
contextGeneratorsMap,
logger,
attachmentManager, // Pass your chosen attachment manager
);
// Send notification with inline file upload
await vintaSend.sendNotification({
notificationTypeId: 'order-confirmation',
userId: '123',
context: { orderNumber: 'ORD-12345' },
attachments: [
{
file: invoiceBuffer,
filename: 'invoice.pdf',
contentType: 'application/pdf',
},
],
});
// Send notification with pre-uploaded file reference
await vintaSend.sendNotification({
notificationTypeId: 'welcome-email',
userId: '456',
context: { userName: 'John' },
attachments: [
{
fileId: 'file-abc-123', // Reference to existing file
description: 'Company brochure',
},
],
});
```
### Complete Documentation
For comprehensive guides on attachment support, storage backends, security, and best practices, see [ATTACHMENTS.md](ATTACHMENTS.md).
Topics covered:
- Available storage backend implementations
- Creating custom AttachmentManagers for any storage service
- Security best practices and performance optimization
- Adapter support for sending attachments
- Usage examples and patterns
## One-Off Notifications
One-off notifications allow you to send notifications directly to an email address or phone number without requiring a user account in your system. This is particularly useful for:
- **Prospects**: Send welcome emails or marketing materials to potential customers
- **Guests**: Invite external participants to events or meetings
- **External Contacts**: Share information with partners or vendors
- **Temporary Recipients**: Send one-time notifications without creating user accounts
### Key Differences from Regular Notifications
| Feature | Regular Notification | One-Off Notification |
|---------|---------------------|----------------------|
| **Recipient** | User ID (requires account) | Email/phone directly |
| **User Data** | Fetched from user table | Provided inline (firstName, lastName) |
| **Use Case** | Registered users | Prospects, guests, external contacts |
| **Storage** | Same table with `userId` | Same table with `emailOrPhone` |
### Creating One-Off Notifications
```typescript
// Send an immediate one-off notification
const notification = await vintaSend.createOneOffNotification({
emailOrPhone: 'prospect@example.com',
firstName: 'John',
lastName: 'Doe',
notificationType: 'EMAIL',
title: 'Welcome!',
bodyTemplate: './templates/welcome.html',
subjectTemplate: 'Welcome to {{companyName}}!',
contextName: 'welcomeContext',
contextParameters: { companyName: 'Acme Corp' },
sendAfter: null, // Send immediately
extraParams: null,
});
```
#### Using with Phone Numbers (SMS)
```typescript
// Send SMS to a phone number (requires SMS adapter)
const smsNotification = await vintaSend.createOneOffNotification({
emailOrPhone: '+15551234567', // E.164 format recommended
firstName: 'John',
lastName: 'Doe',
notificationType: 'SMS',
title: 'Welcome SMS',
bodyTemplate: './templates/welcome-sms.txt',
subjectTemplate: null, // SMS doesn't use subjects
contextName: 'welcomeContext',
contextParameters: { companyName: 'Acme Corp' },
sendAfter: null,
extraParams: null,
});
```
### Database Schema Considerations
One-off notifications are stored in the same table as regular notifications using a unified approach:
- **Regular notifications**: Have `userId` set, `emailOrPhone` is null
- **One-off notifications**: Have `emailOrPhone` set, `userId` is null
## Git Commit SHA Tracking
VintaSend can persist which source-code version executed each notification send/render flow.
### Field behavior
- Persisted notifications include `gitCommitSha: string | null`
- Notification input/resend payloads do not accept this field (`gitCommitSha` is system-managed)
- The SHA is resolved at execution time (send/render), not creation time
### Configuring a provider
Use `BaseGitCommitShaProvider` with `VintaSendFactory.create(...)`.
Preferred factory style (object parameter):
```typescript
import { VintaSendFactory, type BaseGitCommitShaProvider } from 'vintasend';
const gitCommitShaProvider: BaseGitCommitShaProvider = {
getCurrentGitCommitSha: () => process.env.GIT_COMMIT_SHA ?? null,
};
const vintaSend = new VintaSendFactory().create({
adapters: [adapter],
backend,
logger,
contextGeneratorsMap,
gitCommitShaProvider,
});
```
> Positional `create(...)` parameters are still supported for backward compatibility, but object-style configuration is recommended.
### Provider examples
Environment variable (CI/CD injected):
```typescript
const envProvider: BaseGitCommitShaProvider = {
getCurrentGitCommitSha: () => process.env.GIT_COMMIT_SHA ?? null,
};
```
Shell command (async):
```typescript
import { execSync } from 'node:child_process';
const shellProvider: BaseGitCommitShaProvider = {
getCurrentGitCommitSha: async () => {
try {
return execSync('git rev-parse HEAD', { encoding: 'utf-8' }).trim() || null;
} catch {
return null;
}
},
};
```
Static provider (for deterministic environments):
```typescript
const staticProvider: BaseGitCommitShaProvider = {
getCurrentGitCommitSha: () => '0123456789abcdef0123456789abcdef01234567',
};
```
### Migration Guides
#### Migrating to v0.7.0 (Git Commit SHA Tracking)
This migration is only needed if you're using the Prisma backend.
`gitCommitSha` is now persisted on notifications (regular and one-off) as a nullable, system-managed field.
1. Update your Prisma schema (`Notification` model):
- Add `gitCommitSha String?`
- Add `@@index([gitCommitSha])`
2. Run a migration in your app:
```bash
prisma migrate dev --name add-notification-git-commit-sha
```
3. Optionally configure a `BaseGitCommitShaProvider` in `VintaSendFactory`.
4. Do not add `gitCommitSha` to notification create/resend input payloads (it is provider-managed).
#### Migrating to v0.4.0 (Attachment Support)
Version 0.4.0 introduces file attachment support with a **breaking change** to the `VintaSendFactory.create()` method signature.
**Breaking Change**: The `attachmentManager` parameter now comes **before** the `options` parameter.
- **Old signature (v0.3.x)**: `create(adapters, backend, logger, contextGeneratorsMap, queueService?, options?)`
- **New signature (v0.4.0)**: `create(adapters, backend, logger, contextGeneratorsMap, queueService?, attachmentManager?, options?)`
**Migration Steps**:
1. **If you're NOT passing `options`** - No changes needed:
```typescript
// This still works in v0.4.0
factory.create(adapters, backend, logger, contextGeneratorsMap);
factory.create(adapters, backend, logger, contextGeneratorsMap, queueService);
```
2. **If you ARE passing `options` as the 6th argument** - Add `undefined` for `attachmentManager`:
```typescript
// Before (v0.3.x) - THIS WILL BREAK
factory.create(adapters, backend, logger, contextGeneratorsMap, queueService, {
raiseErrorOnFailedSend: true
});
// After (v0.4.0) - CORRECT
factory.create(adapters, backend, logger, contextGeneratorsMap, queueService, undefined, {
raiseErrorOnFailedSend: true
});
```
3. **If you want to use attachments** - Pass the `attachmentManager`:
```typescript
import { LocalFileAttachmentManager } from 'vintasend';
const attachmentManager = new LocalFileAttachmentManager({ uploadDir: './uploads' });
factory.create(adapters, backend, logger, contextGeneratorsMap, queueService, attachmentManager, {
raiseErrorOnFailedSend: true
});
```
4. **For Prisma users**: Add attachment models to your schema (optional, only if you want attachment support):
```bash
# Add AttachmentFile and NotificationAttachment models to schema.prisma
# See ATTACHMENTS.md for the complete schema
prisma migrate dev --name add-attachment-support
```
**Note**: Attachment methods in `BaseNotificationBackend` are now **optional**. Existing backend implementations continue to work without changes. See [ATTACHMENTS.md](ATTACHMENTS.md) for full documentation.
#### Migrating to v0.3.0 (One-off Notifications)
If you're adding one-off notification support to an existing installation:
1. **Update your Prisma schema** to make `userId` optional and add one-off fields:
```bash
# Add the new fields to your schema.prisma
# Then run:
prisma migrate dev --name add-one-off-notification-support
```
2. **No code changes required** for existing functionality - all existing notifications continue to work as before.
3. **Existing notifications are preserved** - they have `userId` set and `emailOrPhone` as null.
## Glossary
* **Notification Backend**: It is a class that implements the methods necessary for VintaSend services to create, update, and retrieve Notifications from the database.
* **Notification Adapter**: It is a class that implements the methods necessary for VintaSend services to send Notifications through email, SMS or even push/in-app notifications.
* **Template Renderer**: It is a class that implements the methods necessary for VintaSend adapter to render the notification body.
* **Notification Context**: It's the data passed to the templates to render the notification correctly. It's generated when the notification is sent, not on creation time
* **Context generator**: It's a class defined by the user context generator map with a context name. That class has a `generate` method that, when called, generates the data necessary to render its respective notification.
* **Context name**: The registered name of a context generator. It's stored in the notification so the context generator is called at the moment the notification will be sent.
* **Context generators map**: It's an object defined by the user that maps context names to their respective context generators.
* **Queue service**: Service for enqueueing notifications so they are sent by an external service.
* **Logger**: A class that allows the `NotificationService` to create logs following a format defined by its users.
* **One-off Notification**: A notification sent directly to an email address or phone number without requiring a user account. Used for prospects, guests, or external contacts.
* **Regular Notification**: A notification associated with a user account (via userId). Used for registered users in your system.
* **AttachmentManager**: A class that handles file storage operations (upload, download, delete) for notification attachments. Supports S3, Azure, GCS, and custom storage backends.
* **Attachment**: A file attached to a notification, either uploaded inline or referenced from previously uploaded files. Supports automatic deduplication and reuse across multiple notifications.
## Implementations
### Community
VintaSend has many backend, adapter, and template renderer implementations. If you can't find something that fulfills your needs, the package has very clear interfaces you can implement and achieve the exact behavior you expect without loosing VintaSend's friendly API.
#### Officially supported packages
##### Backends
* **[vintasend-prisma](https://github.com/vintasoftware/vintasend-ts-prisma/)**: Uses Prisma Client to manage the notifications in the database.
* **[vintasend-medplum](https://github.com/vintasoftware/vintasend-medplum/)**: Uses Medplum FHIR resources (Communication, Binary, Media) to manage notifications in healthcare applications.
##### Adapters
* **[vintasend-nodemailer](https://github.com/vintasoftware/vintasend-nodemailer/)**: Uses nodemailer to send transactional emails to users.
* **[vintasend-sendgrid](https://github.com/vintasoftware/vintasend-ts-sendgrid/)**: Uses SendGrid's API to send transactional emails with attachment support.
* **[vintasend-medplum](https://github.com/vintasoftware/vintasend-medplum/)**: Uses Medplum's email API to send notifications in healthcare applications.
* **[vintasend-mailgun](https://github.com/vintasoftware/vintasend-ts-mailgun/)**: Uses Mailgun's API to send transactional emails with attachment support.
* **[vintasend-twilio](https://github.com/vintasoftware/vintasend-ts-twilio/)**: Uses Twilio's API to send transactional SMS.
##### Attachment Managers
* **[vintasend-aws-s3-attachments](https://github.com/vintasoftware/vintasend-aws-s3-attachments/)**: AWS S3 storage backend with presigned URLs and streaming support. Also works with S3-compatible services (MinIO, DigitalOcean Spaces, Cloudflare R2, etc.).
* **[vintasend-medplum](https://github.com/vintasoftware/vintasend-medplum/)**: FHIR-compliant file storage using Binary and Media resources for healthcare applications.
##### Template Renderers
* **[vintasend-pug](https://github.com/vintasoftware/vintasend-pug/)**: Renders emails using Pug.
* **[vintasend-react-email](https://github.com/vintasoftware/vintasend-react-email/)**: Renders emails using React Email, including uncompiled TS/TSX template support.
##### Loggers
* **[vintasend-winston](https://github.com/vintasoftware/vintasend-winston/)**: Uses Winston to allow `NotificationService` to create log entries.
* **[vintasend-medplum](https://github.com/vintasoftware/vintasend-medplum/)**: Simple console-based logger for Medplum applications.
## Examples
Examples of how to use VintaSend in different context are available on the [vintasend-ts-examples repository](https://github.com/vintasoftware/vintasend-ts-examples).
## Development
1. Clone the repository
2. Install dependencies:
```bash
npm install
# or
yarn
```
3. Run tests:
```bash
npm test
# or
yarn test
```
## Contributing
Feel free to open issues and submit pull requests.
### Release Process
This project uses a two-step automated release process:
1. **Bump versions**: `npm run release:bump`
2. **Update CHANGELOG.md**: Edit manually
3. **Publish**: `npm run release:publish`
Optional publish skips:
- `npm run release:publish -- --skip=vintasend-medplum,vintasend-ts-twilio`
- `npm run release:publish -- --skip-root`
- `npm run release:publish -- --skip=root,vintasend-medplum`
For detailed instructions, see:
- [Release Guide](RELEASE_GUIDE.md) - Complete walkthrough with examples
- [Quick Reference](RELEASE_QUICK_REF.md) - Command cheatsheet
- [Technical Docs](scripts/README.md) - Script architecture details
### Creating new implementations
There's a template project for creating new implementations that already includes basic dependencies, configuration for tests, and Github Actions hooks. You can find it in [vintasend-ts/src/implementations/vintasend-implementation-template](https://github.com/vintasoftware/vintasend-ts/tree/main/src/implementations/vintasend-implementation-template)
## License
This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
## Commercial Support
[](https://www.vinta.com.br/)
This project is maintained by [Vinta Software](https://www.vinta.com.br/) and is used in products of Vinta's clients. We are always looking for exciting work! If you need any commercial support, feel free to get in touch: contact@vinta.com.br