@cdmbase/wiki-browser 12.0.18-alpha.10

package/lib/templates/content/docs/server-side/e2b/manageing-template.md

@@ -0,0 +1,197 @@
+# E2B Sandbox Template Building Guide (v1)
+
+## Overview
+
+Sandbox templates in E2B v1 allow you to customize sandbox environments for your specific needs. Templates define the base image, dependencies, startup commands, and resource allocations for sandboxes. Once built and published, templates can be referenced by ID when creating new sandboxes via the SDK.
+
+## Version
+
+This guide covers **E2B v1** template management. We are currently using v1 for Yantra AI production work.
+
+## Prerequisites
+
+### Install E2B CLI v1.9.2
+
+Before building templates, install the E2B CLI:
+
+```bash
+npm install -g @e2b/cli@1.9.2
+```
+
+Verify installation:
+
+```bash
+e2b --version
+```
+
+## Building and Publishing Templates
+
+### Command Structure
+
+```bash
+export E2B_API_URL="https://e2bdashboard.cdebase.dev" && \
+export E2B_ACCESS_TOKEN=xxxx && \
+export E2B_DOMAIN=yarntra.ai && \
+e2b template build -c "/start-services.sh" \
+  --name next-keycloak-new-latest-test \
+  --cpu-count 4 \
+  --memory-mb 4096
+```
+
+### Parameter Explanation
+
+| Parameter          | Purpose                                                                                                                       |
+| ------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
+| `E2B_API_URL`      | Custom E2B dashboard endpoint for your infrastructure                                                                         |
+| `E2B_ACCESS_TOKEN` | Authentication token for E2B API access                                                                                       |
+| `E2B_DOMAIN`       | Your domain (yantra.ai)                                                                                                       |
+| `-c, --cmd`        | Start command executed when sandbox launches (e.g., `/start-services.sh`)                                                     |
+| `--name`           | Template name used to identify and reference the template in code (must be lowercase, alphanumeric, dashes, underscores only) |
+| `--cpu-count`      | Number of CPU cores allocated to the sandbox (e.g., 4)                                                                        |
+| `--memory-mb`      | Memory allocation in megabytes (e.g., 4096 = 4GB, must be even number)                                                        |
+
+### Template Configuration File
+
+When you run `e2b template build`, E2B automatically creates an `e2b.toml` configuration file in your project root. This file stores metadata about your template, including its ID and name.
+
+## ⚠️ CRITICAL: Template Management Instructions
+
+### When Building a NEW Template
+
+If you are creating a **brand new template** for a different project or use case:
+
+1. **DELETE the existing `e2b.toml` file** before running the build command
+    ```bash
+    rm e2b.toml
+    ```
+2. **ALWAYS change the `--name` parameter** to a unique, descriptive name
+    - Example: `next-keycloak-new-latest-test` (existing)
+    - For a new auth project: `--name auth-service-custom-template`
+    - For a data processing sandbox: `--name data-processor-v1`
+    - For a code execution environment: `--name code-interpreter-advanced`
+
+3. **Rationale**: Without deleting `e2b.toml` and changing the name, the CLI will UPDATE the existing template instead of creating a new one. Since our current templates are actively used in production migration work, updating them accidentally would break running sandboxes.
+
+### When Updating an Existing Template
+
+If you are **deliberately updating** a template already in use:
+
+1. **Keep the `e2b.toml` file** as-is
+2. **Use the same `--name`** as the existing template
+3. **Coordinate with the team** before updating to avoid disrupting active workflows
+4. **Test thoroughly** before deploying updates
+
+## Typical Workflow
+
+### Step 1: Set Environment Variables
+
+```bash
+export E2B_API_URL="https://e2bdashboard.cdebase.dev"
+export E2B_ACCESS_TOKEN="your_token_here"
+export E2B_DOMAIN="yarntra.ai"
+```
+
+### Step 2: Prepare Your Dockerfile
+
+Create an `e2b.Dockerfile` or `Dockerfile` in your project root with the dependencies and configuration your sandbox needs.
+
+Example structure:
+
+```dockerfile
+FROM ubuntu:22.04
+
+# Install base dependencies
+RUN apt-get update && apt-get install -y \
+    curl \
+    git \
+    nodejs \
+    npm
+
+# Copy your application
+COPY . /app
+WORKDIR /app
+
+# Install application dependencies
+RUN npm install
+```
+
+### Step 3: Build and Publish
+
+For a new template:
+
+```bash
+rm e2b.toml  # Delete existing config if present
+
+export E2B_API_URL="https://e2bdashboard.cdebase.dev" && \
+export E2B_ACCESS_TOKEN=xxxx && \
+export E2B_DOMAIN=yarntra.ai && \
+e2b template build \
+  -c "/start-services.sh" \
+  --name my-custom-template-unique-name \
+  --cpu-count 4 \
+  --memory-mb 4096
+```
+
+### Step 4: Use the Template
+
+Once built, you can create sandboxes using the template ID or name:
+
+**JavaScript/TypeScript:**
+
+```javascript
+import { Sandbox } from 'e2b';
+const sandbox = await Sandbox.create('my-custom-template-unique-name');
+```
+
+**Python:**
+
+```python
+from e2b import Sandbox
+sandbox = Sandbox.create('my-custom-template-unique-name')
+```
+
+## Key Considerations
+
+### Resource Allocation
+
+- **CPU Count**: Allocate based on expected workload. Min 1, typical production values 2-4
+- **Memory**: Must be an even number. Common values: 512 (minimal), 1024 (standard), 2048-4096 (resource-intensive)
+
+### Naming Conventions
+
+- Use lowercase letters, numbers, dashes, and underscores only
+- Be descriptive: `next-keycloak-new-latest-test`, `python-data-processor`, `node-api-server`
+- Avoid generic names like `template-1` or `test-v2`
+
+### Start Commands
+
+- The command specified with `-c` runs when the sandbox starts
+- Common patterns: service startup scripts, shell initialization, environment setup
+- Example: `-c "/start-services.sh"` executes your startup script
+
+## Troubleshooting
+
+### Template Already Exists Error
+
+If you get an error that the template name already exists, either:
+
+1. Use a different `--name` value for a new template
+2. Or deliberately update the existing template (confirm with team first)
+
+### Build Failures
+
+- Check that your Dockerfile is valid
+- Verify all required dependencies are installed
+- Ensure start commands are executable in the container
+
+### Performance Issues
+
+- Monitor sandbox startup time
+- If slow, optimize your Dockerfile (reduce layer count, cache dependencies)
+- Consider reducing CPU/memory if over-allocated
+
+## References
+
+- [E2B v1 Sandbox Template Docs](https://e2b.dev/docs/sandbox-template)
+- [E2B v1 CLI Reference](https://e2b.dev/docs/sdk-reference/cli)
+- [E2B Dashboard](https://e2bdashboard.cdebase.dev)

package/lib/templates/content/docs/server-side/index.md

@@ -0,0 +1,14 @@
+---
+meta:
+    title: Server Side
+    description: Server Side
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Server Side...
+headers:
+    Cache-Control: no-cache
+---
+
+## Server Side
+
+**[Account Customization](/docs/server-side/account-customization)**

package/lib/templates/content/docs/server-side/inngest-functions-module.md

@@ -0,0 +1,309 @@
+# Inngest Functions Integration Guide
+
+This guide shows how to integrate Inngest functions with the common-stack Feature system, providing automatic dependency injection and modular organization.
+
+## Quick Start
+
+The system automatically provides the `/api/inngest` endpoint when you register Inngest functions through the Feature system.
+
+## Basic Usage
+
+### 1. Create Your Function Factory
+
+Create a function factory that receives the DI container and returns your Inngest functions:
+
+```typescript
+import { Container } from 'inversify';
+import { inngest } from './client'; // Your Inngest client
+
+export const myInngestFunctions = ({ container, inngest, settings }) => {
+    // Access any service from the container
+    const userService = container.get('UserService');
+    const logger = container.get('Logger');
+    const mongoConnection = container.get('MongoDBConnection');
+    const pubsub = container.get('PubSub');
+
+    return {
+        myFunction: inngest.createFunction({ id: 'my-function' }, { event: 'my.event' }, async ({ event, step }) => {
+            // Use services in your function
+            const user = await userService.getUser(event.data.userId);
+            logger.info('Processing event for user:', user.id);
+
+            await pubsub.publish('USER_PROCESSED', { userId: user.id });
+
+            return { success: true };
+        }),
+    };
+};
+```
+
+### 2. Register with Feature System
+
+```typescript
+import { Feature } from '@common-stack/server-core';
+import { myInngestFunctions } from './my-functions';
+
+export const MyFeature = new Feature({
+    inngestFunctions: [myInngestFunctions], // Array of function factories
+
+    // Other feature properties...
+    schema: [],
+    createResolversFunc: [],
+    createContainerFunc: [],
+});
+```
+
+### 3. Automatic Registration
+
+That's it! The system automatically:
+
+- ✅ Loads your functions with full DI container access
+- ✅ Registers the `/api/inngest` endpoint
+- ✅ Preserves all Inngest function properties and behaviors
+
+## Advanced Examples
+
+### Multiple Function Factories per Feature
+
+```typescript
+import { Feature } from '@common-stack/server-core';
+import { userInngestFunctions, emailCampaignInngestFunctions, analyticsInngestFunctions } from './functions';
+
+export const MultiModuleFeature = new Feature({
+    // Use array of function factories - each gets container access
+    inngestFunctions: [userInngestFunctions, emailCampaignInngestFunctions, analyticsInngestFunctions],
+});
+```
+
+### Individual Function Factories
+
+#### User Management Functions
+
+```typescript
+// user-functions.ts
+export const userInngestFunctions = ({ container, inngest, settings }) => {
+    const userService = container.get('UserService');
+    const emailService = container.get('EmailService');
+
+    return {
+        createUser: inngest.createFunction({ id: 'create-user' }, { event: 'user.create' }, async ({ event }) => {
+            const user = await userService.createUser(event.data);
+            await emailService.sendWelcomeEmail(user.email);
+            return { success: true, userId: user.id };
+        }),
+        updateProfile: inngest.createFunction(
+            { id: 'update-profile' },
+            { event: 'user.profile.update' },
+            async ({ event }) => {
+                const updatedUser = await userService.updateProfile(event.data);
+                return { success: true, user: updatedUser };
+            },
+        ),
+    };
+};
+```
+
+#### Email Campaign Functions
+
+```typescript
+// email-functions.ts
+export const emailInngestFunctions = ({ container, inngest, settings }) => {
+    const emailService = container.get('EmailService');
+    const campaignService = container.get('CampaignService');
+
+    return {
+        sendCampaign: inngest.createFunction(
+            { id: 'send-campaign' },
+            { event: 'email.campaign.send' },
+            async ({ event }) => {
+                const result = await campaignService.sendCampaign(event.data.campaignId);
+                return { success: true, emailsSent: result.count };
+            },
+        ),
+        trackEmailOpen: inngest.createFunction(
+            { id: 'track-email-open' },
+            { event: 'email.opened' },
+            async ({ event }) => {
+                await campaignService.trackOpen(event.data);
+                return { success: true };
+            },
+        ),
+    };
+};
+```
+
+### Using Pre-defined Function Collections
+
+```typescript
+import { Feature } from '@common-stack/server-core';
+import { allInngestFunctionFactories } from '../inngest/multi-module-functions';
+
+export const MultiModuleFeature = new Feature({
+    // Use pre-defined collection of function factories
+    inngestFunctions: allInngestFunctionFactories,
+});
+```
+
+## Function Factory Signature
+
+Your function factories must follow this signature:
+
+```typescript
+type InngestFunctionFactory = ({
+    container,
+    inngest,
+    settings,
+}: {
+    container: Container;
+    inngest: any;
+    settings?: any;
+}) => Record<string, any>;
+```
+
+### Parameters:
+
+- **`container`**: Inversify DI container with all your services
+- **`inngest`**: Inngest client instance
+- **`settings`**: Optional additional settings
+
+## Available Services
+
+Common services available in the container:
+
+```typescript
+// Core Services
+const logger = container.get('Logger');
+const mongoConnection = container.get('MongoDBConnection');
+const pubsub = container.get('PubSub');
+const redisClient = container.get(CommonType.REDIS_CLIENT);
+const moleculerBroker = container.get(CommonType.MOLECULER_BROKER);
+
+// Your Custom Services
+const userService = container.get('UserService');
+const emailService = container.get('EmailService');
+const analyticsService = container.get('AnalyticsService');
+```
+
+## Best Practices
+
+### 1. Organize by Domain
+
+```typescript
+// user-functions.ts - All user-related functions
+// email-functions.ts - All email-related functions
+// analytics-functions.ts - All analytics functions
+```
+
+### 2. Use Descriptive Function IDs
+
+```typescript
+inngest.createFunction(
+    { id: 'user-onboarding-send-welcome-email' }, // Clear, descriptive ID
+    { event: 'user.created' },
+    async ({ event }) => {
+        /* ... */
+    },
+);
+```
+
+### 3. Error Handling
+
+```typescript
+export const myInngestFunctions = ({ container, inngest, settings }) => {
+    const logger = container.get('Logger');
+
+    return {
+        myFunction: inngest.createFunction({ id: 'my-function' }, { event: 'my.event' }, async ({ event, step }) => {
+            try {
+                // Your function logic
+                return { success: true };
+            } catch (error) {
+                logger.error('Function failed:', error);
+                throw error; // Let Inngest handle retries
+            }
+        }),
+    };
+};
+```
+
+### 4. Use Step Functions for Complex Workflows
+
+```typescript
+export const complexWorkflowFunctions = ({ container, inngest, settings }) => {
+    const userService = container.get('UserService');
+    const emailService = container.get('EmailService');
+    const paymentService = container.get('PaymentService');
+
+    return {
+        processOrder: inngest.createFunction(
+            { id: 'process-order' },
+            { event: 'order.created' },
+            async ({ event, step }) => {
+                const user = await step.run('get-user', async () => {
+                    return userService.getUser(event.data.userId);
+                });
+
+                const payment = await step.run('process-payment', async () => {
+                    return paymentService.processPayment(event.data.payment);
+                });
+
+                await step.run('send-confirmation', async () => {
+                    return emailService.sendOrderConfirmation(user.email, event.data);
+                });
+
+                return { success: true, orderId: event.data.orderId };
+            },
+        ),
+    };
+};
+```
+
+## Automatic Features
+
+The system automatically provides:
+
+- ✅ **Endpoint Registration**: `/api/inngest` endpoint is automatically available
+- ✅ **Dependency Injection**: Full container access in all functions
+- ✅ **Function Discovery**: Automatically finds and loads all registered functions
+- ✅ **Error Handling**: Proper error logging and handling
+- ✅ **Development Support**: Works in both development and production environments
+
+## Troubleshooting
+
+### No Functions Loaded
+
+- Check that your function factory is properly exported
+- Ensure the factory is included in the Feature's `inngestFunctions` array
+- Verify the function factory signature matches the expected interface
+
+### Container Services Not Available
+
+- Ensure your services are properly bound in the container modules
+- Check service binding keys match what you're trying to get
+- Verify the container is properly initialized before Inngest setup
+
+### Functions Not Appearing at `/api/inngest`
+
+- Check server logs for any registration errors
+- Verify Inngest configuration (event key, signing key, etc.)
+- Ensure the Feature is properly included in your main server setup
+
+## Configuration
+
+Environment variables for Inngest:
+
+```env
+INNJEST_EVENT_KEY=your_event_key
+INNJEST_SIGNING_KEY=your_signing_key
+INNJEST_IS_DEV=true
+INNJEST_ENVIRONMENT=development
+```
+
+## Next Steps
+
+1. Create your function factories following the examples above
+2. Register them with the Feature system
+3. Your functions will be automatically available at `/api/inngest`
+4. Use Inngest's dashboard to monitor and manage your functions
+
+For more advanced Inngest features, refer to the [official Inngest documentation](https://www.inngest.com/docs).

package/lib/templates/content/docs/server-side/listen-stripe-events.md

@@ -0,0 +1,43 @@
+---
+meta:
+    title: Listen Stripe Events
+    description: Listen Stripe Events
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Listen Stripe Events...
+headers:
+    Cache-Control: no-cache
+---
+
+## Use Stripe CLI to simulate Stripe events in your local environment or learn more about Webhooks.
+
+### step 1
+
+[Download the CLI](https://stripe.com/docs/stripe-cli) and log in with your Stripe account
+
+```
+stripe login
+```
+
+In the browser make sure you are in the correct tenent of the project.
+
+note down the webhook token and save it in your env as `STRIPE_ENDPOINT_SECRET`
+
+restart the backend
+
+### step 2
+
+Forward events to your webhook
+
+```
+stripe listen --forward-to localhost:8080/webhook/stripe
+```
+
+### Trigger events with the CLI
+
+```
+stripe trigger payment_intent.succeeded
+```
+
+Check source:
+https://dashboard.stripe.com/webhooks/create?endpoint_location=local