Vendor Isolation & Security
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Vendor Isolation & Security in the Wrelik ecosystem is achieved through an "adapter-first" architecture that establishes a strict boundary between application code and third-party service providers. The primary goal is to minimize vendor lock-in, enforce consistent security patterns, and reduce the surface area exposed to external SDKs. By wrapping vendor-specific functionality in internal packages, the system ensures that switching a provider (e.g., from one storage provider to another) only requires updates within a single adapter package rather than across the entire application suite.
Sources: README.md:5-13, DECISIONS.md:14-19
Adapter-First Architecture
The project utilizes a monorepo structure to house shared packages that act as the exclusive gateway to third-party services. This design pattern ensures that applications remain "vendor-agnostic" by consuming standardized internal APIs.
Core Implementation Principles
- No Direct SDK Usage: Application repositories are strictly prohibited from importing vendor SDKs directly.
- Explicit Boundaries: Each package defines a minimal surface area, exposing only the specific functionality required by the apps.
- Standardized Integrations: The repository acts as the infrastructure layer to enforce discipline across the ecosystem.
Sources: README.md:7-13, README.md:46-48
Architectural Flow of Vendor Integration
The following diagram illustrates how applications interact with the infrastructure through the isolation layer provided by @wrelik packages.
This diagram represents the flow where application code only communicates with internal adapters, which in turn manage the complex interactions with third-party vendor SDKs.
Sources: README.md:16-41, DECISIONS.md:4-12
Security & Access Enforcement
Security is enforced through centralizing sensitive logic such as Role-Based Access Control (RBAC), multi-tenant data isolation, and environment variable validation.
Authentication and RBAC
The @wrelik/auth package manages session handling and user validation. It abstracts the Clerk SDK to provide consistent authentication checks across the platform.
| Component | Responsibility | Relevant Tooling |
|---|---|---|
| Session Parsing | Converts vendor-specific auth objects into standard internal session formats. | @clerk/backend |
| RBAC | Validates roles (e.g., 'admin') within session metadata. | @wrelik/auth |
| User Enforcement | Provides helpers like requireUser to throw standardized errors when sessions are missing. | @wrelik/errors |
Sources: packages/auth/src/index.test.ts:5-28, packages/auth/package.json:20-22
Multi-Tenancy and Database Security
The @wrelik/db package is responsible for the Prisma client singleton and enforcing safe multi-tenant access patterns. This ensures that data belonging to one organization cannot be accessed by another within the same Postgres instance.
Sources: README.md:21-23, packages/db/package.json:16
Enforcement via Tooling
Isolation is not just a convention but is actively enforced through shared configuration and linting rules.
ESLint Restricted Imports
The @wrelik/eslint-config package includes strict no-restricted-imports rules. These rules prevent developers from bypassing the isolation layer by throwing linting errors if direct vendor imports are detected.
// Example of restricted paths in packages/eslint-config/index.js
rules: {
'no-restricted-imports': [
'error',
{
paths: [
{ name: '@clerk/nextjs', message: 'Please use @wrelik/auth instead.' },
{ name: '@prisma/client', message: 'Please use @wrelik/db instead.' },
{ name: 'resend', message: 'Please use @wrelik/email instead.' }
],
patterns: [
{ group: ['@aws-sdk/*'], message: 'Please use @wrelik/storage instead.' }
]
}
]
}
Sources: packages/eslint-config/index.js:15-46
Typed Configuration
The @wrelik/config package uses Zod to load and validate environment variables. This ensures that all necessary vendor credentials (API keys, secrets) are present and correctly formatted at runtime, preventing silent failures in the security layer.
Sources: README.md:31-33, packages/config/package.json:16-17
Summary of Vendor Mappings
The project defines a standard stack while maintaining the flexibility to swap components through the adapter layer.
| Domain | Vendor | Shared Package |
|---|---|---|
| Auth | Clerk | @wrelik/auth |
| Database | Neon (Prisma) | @wrelik/db |
| Storage | Cloudflare R2 | @wrelik/storage |
| Analytics | PostHog | @wrelik/analytics |
| Resend | @wrelik/email |
Sources: DECISIONS.md:4-12
Conclusion
Vendor Isolation & Security in this repository is a multi-layered strategy involving code wrappers, centralized error handling, and automated linting. By treating the integration layer as long-lived infrastructure, the system protects application logic from external API changes and enforces a uniform security posture across the entire Wrelik ecosystem.