001-drive-proxy-adapter #1
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: verint.com/google-drive-content-adapter#1
Reference in New Issue
Block a user
Delete Branch "001-drive-proxy-adapter"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
First version that loads the sitemap.xml only but established a constitution for developing proxy scripts with globa variables and functions.
Changes: - Change tempContext from minimal {crypto, console: logger} - Now uses {...globalVMContext, ...globalVariableContext} - Provides function modules access to all VM globals - Matches the context pattern used for proxy.js Benefits: - Function modules can access all dependencies (axios, jwt, etc.) - Consistent with per-request context pattern - Previously loaded JSON data available to function modules - More flexible for complex function modules Context now includes: - From globalVMContext: URLSearchParams, URL, console, crypto, axios, uuidv4, jwt, xmlBuilder - From globalVariableContext: Previously loaded JSON files and function modules - Allows function modules to depend on other globals if needed Testing: - ✓ Syntax validated - ✓ helpers.js loads correctly with full context - ✓ helpers.generateRequestId() uses crypto from context - ✓ All 11 exports available Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Version: 1.17.0 → 1.18.0 (MINOR: Function loading pattern documentation) Changes: - Document loadGlobalVariableFunctions() generic pattern - Update VM context injection code example - Update helpers.js loading documentation - Document tempContext with full globalVMContext + globalVariableContext - Fix duplicate req entry and renumber to 11 and 12 Key Documentation Updates: 1. Section I.II - helpers.js Pattern: - Loaded by loadGlobalVariableFunctions() which scans ALL .js files - Filename determines key: helpers.js → globalVariableContext.helpers - Executed in tempContext with full VM globals access 2. Section I.V - VM Context Injection Pattern: - Replaced specific helpers loading code with generic pattern - Documents loadGlobalVariableFunctions() scanning all .js files - Shows tempContext creation with {...globalVMContext, ...globalVariableContext} - Documents 4-step loading process with filename-to-key mapping 3. Section I.V - Helper Functions Module: - Added Generic Loading Pattern section - Documents full access to VM globals (axios, jwt, crypto, etc.) - Documents access to previously loaded JSON data and functions - Added note about extensibility (utils.js, validators.js, etc.) Architecture Notes: - Generic pattern: any .js file in globalVariables/ auto-loaded - tempContext includes all dependencies from both contexts - Function modules can access same globals as proxy.js - Supports multiple function modules without code changes Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Simplification: - Combine loadGlobalObjects() + loadGlobalVariableFunctions() → loadGlobalVariables() - Single function handles both .json and .js files - Reduced from 258 to 234 lines (24 lines saved, ~9% reduction) Benefits: - Simpler API: One function instead of two - Clearer intent: Load all global variables regardless of type - Less duplication: Shared error handling and logging - Better logging: Summary shows json: N, js: M breakdown - Same behavior: JSON loaded first, then JS (maintains order) Implementation: - Filter for both .json and .js files in one pass - Separate into jsonFiles and jsFiles arrays - Process JSON files first (data) - Process JS files second (can reference JSON data) - Single summary log with breakdown: {json: 1, js: 1} Changes: - Renamed: loadGlobalObjects() → removed - Renamed: loadGlobalVariableFunctions() → removed - Added: loadGlobalVariables() - unified loader - Updated: startServer() - single loader call - Improved: Error messages now consistent ('Failed to load {file}') - Improved: Log messages ('Loaded global data' vs 'Loaded global functions') Testing: - ✓ Syntax validated - ✓ Both JSON and JS files load correctly - ✓ Correct load order (JSON first, JS second) - ✓ All 2 files loaded successfully - ✓ helpers.generateRequestId() works Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Reduced from 234 to 183 lines (51 lines saved, 22% reduction) Changes: 1. **Simplified loadGlobalVariables()** (69 lines → 33 lines) - Single-pass file scan with immediate categorization - Removed nested try-catch blocks (let errors bubble up naturally) - Inline file processing (no separate temp variables) - Cleaner: file.includes('.example') check - More concise logging 2. **Streamlined loadConfig()** (14 lines → 13 lines) - Immutable object spreading instead of mutation - Clearer structure shows ENV precedence - Removed redundant comments 3. **Simplified validateConfig()** (17 lines → 5 lines) - Direct error throw instead of error array accumulation - Single validation check (can expand as needed) - Removed JSDoc params (types obvious from code) 4. **Reduced redundant comments** - Removed comments that restate what code clearly shows - Kept essential pattern documentation - Removed JSDoc for obvious parameters Benefits: - ✅ Same functionality, cleaner code - ✅ Fewer lines to maintain - ✅ Faster file scanning (single pass) - ✅ Simpler error handling (natural bubbling) - ✅ More readable (less nesting) - ✅ Immutable config merging (safer) Testing: - ✓ Syntax validated - ✓ Server starts successfully - ✓ Both JSON and JS files load correctly - ✓ All 2 global variables loaded - ✓ Configuration merging works Philosophy: - Conservative approach: Maintain clarity while removing redundancy - Follow DRY principle: Eliminate duplicate filtering/processing - Let code speak: Remove comments that restate obvious logic - Simpler error handling: Let errors bubble naturally Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Changed from IIFE pattern to direct object literal evaluation Rationale: - Global variable functions should evaluate to an object directly - IIFE wrapper was unnecessary complexity - Simpler pattern: code evaluates to object, not function that returns object - Matches intended architecture for vm.Script module loading Changes: 1. Removed IIFE wrapper: - Before: (function createHelpers() { ... return {...} })() - After: ({ ... }) 2. Removed function indentation (2 spaces throughout file) 3. Updated constitution.md: - Pattern description: 'IIFE returning object' → 'evaluates to a single object' - Clarified: 'not wrapped in IIFE' - Updated all pattern references Structure: - File defines classes and functions at top level - Final expression is object literal referencing all functions - When executed via vm.Script, evaluates to the object - Object is assigned to globalVariableContext.googleDriveAdapterHelper Benefits: ✅ Simpler pattern (no function wrapper) ✅ Clearer intent (direct object evaluation) ✅ Matches architecture description ✅ Easier to understand and maintain ✅ Same functionality, cleaner implementation Before (IIFE): After (Object Literal): Testing: ✓ Syntax validated ✓ Server starts successfully ✓ Module loads: 'Loaded global functions: googleDriveAdapterHelper' ✓ All function calls work correctly ✓ Request handling works as expected Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Reverted from object literal to function with return statement Rationale: - User requested explicit 'return' statement for clarity - Function wrapper with 'return' is more conventional and readable - Makes it clear the code returns an object when executed - Matches common module pattern expectations Structure: ```javascript (function() { // Define all classes and functions class DocumentCountExceededError extends Error {...} function generateRequestId() {...} // ... all other functions // Return object with all exports return { DocumentCountExceededError, generateRequestId, // ... all other functions }; })(); ``` Changes: - Wrapped entire file in IIFE: (function() { ... })() - Changed final expression from ({ ... }) to return { ... }; - Re-added 2-space indentation for content inside function - Updated header comment: 'Returns' → 'Function that returns' Benefits: ✅ Explicit return statement (clearer intent) ✅ Standard IIFE module pattern ✅ More conventional JavaScript style ✅ Easier to understand for new developers ✅ Same functionality as before Testing: ✓ Syntax validated ✓ Server starts successfully ✓ Module loads: 'Loaded global functions: googleDriveAdapterHelper' ✓ All function calls work correctly ✓ Request handling functional Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Simplified to pure object literal expression Rationale: - User requested to forget about IIFE wrapper - Simpler pattern: file evaluates directly to an object - No function wrapper needed - No return statement needed - server.js already handles this correctly at line 59 Pattern: ```javascript // Define functions at top level class DocumentCountExceededError extends Error {...} function generateRequestId() {...} function parseRoute() {...} // Final expression evaluates to object ({ DocumentCountExceededError, generateRequestId, parseRoute, // ... all functions }); ``` How server.js handles it (already correct): ```javascript const script = new vm.Script(code, { filename: file }); const context = vm.createContext({ ...globalVMContext, ...globalVariableContext }); globalVariableContext[varName] = script.runInContext(context); // script.runInContext() returns the evaluated expression (the object) ``` Changes: - Reverted from IIFE with return: (function() { return {...}; })() - Back to object literal: ({...}) - Removed 2-space indentation throughout - No function wrapper - No return statement Benefits: ✅ Simplest possible pattern ✅ Direct object evaluation ✅ No syntax complexity ✅ Server.js already handles it correctly ✅ Clean, minimal code Testing: ✓ Syntax validated ✓ Server starts successfully ✓ Module loads: 'Loaded global functions: googleDriveAdapterHelper' ✓ All function calls work correctly ✓ Request handling functional Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Changed architecture so .js files contain literal function bodies Changes to googleDriveAdapterHelper.js: 1. Changed from object literal (\({...}\)) to return statement (return {...}) 2. File now contains LITERAL BODY of a function 3. Updated header comment to explain this pattern 4. File is NO LONGER valid standalone JavaScript (has bare return) Changes to server.js loadGlobalVariables(): 1. Wrap loaded code in function: `(function() { ${code} })()` 2. Creates IIFE that executes the function body 3. Captures returned object from the function 4. Pattern applies to ALL .js files in globalVariables/ Pattern: ```javascript // File: googleDriveAdapterHelper.js (literal function body) class DocumentCountExceededError extends Error {...} function generateRequestId() {...} return { DocumentCountExceededError, generateRequestId, // ... all exports }; ``` ```javascript // server.js wraps it: const wrappedCode = `(function() { ${code} })()`; const script = new vm.Script(wrappedCode, { filename: file }); const returnedObject = script.runInContext(context); ``` Benefits: ✅ Files represent pure function bodies ✅ Wrapping logic centralized in server.js ✅ Clear separation: content vs. execution wrapper ✅ Explicit return statement in function body ✅ Consistent pattern for all global variable functions ✅ Easy to understand: file = function body, server = wrapper Testing: ✓ Server starts successfully ✓ Module loads: 'Loaded global functions: googleDriveAdapterHelper' ✓ Object captured: type=object, keys=11 ✓ All functions accessible in VM context ✓ proxy.js can call googleDriveAdapterHelper.* functions Note: googleDriveAdapterHelper.js will show syntax error if run standalone (has bare return statement) - this is intentional, it's a function body! Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>Updated constitution.md to reflect the new loading pattern for global variables: Version: 1.19.0 → 1.20.0 (MINOR) Changes documented: 1. Section I.II: Updated googleDriveAdapterHelper.js pattern - Files contain LITERAL BODY of a function - Use bare 'return {...}' statement (NOT valid standalone JS) - server.js wraps code in IIFE: (function() { <code> })() - Clear separation: file = content, server = wrapper 2. Section I.V: Updated loadGlobalVariables() pattern - Shows wrapping logic with code examples - Explains IIFE creation and execution - Documents context creation and object capture 3. Added comprehensive examples: - Example file structure showing literal function body - Example server.js wrapping logic with vm.Script - Shows how return statement exports object 4. Version history updated: - Documented architecture changes - Explained rationale for pattern - Listed benefits of approach Key pattern documented: ✅ .js files in globalVariables/ contain function bodies with return ✅ Files are NOT valid standalone JavaScript (intentional) ✅ server.js wraps them: '(function() { <code> })()' ✅ Wrapping creates IIFE that executes and returns object ✅ Pattern applies to ALL .js files in globalVariables/ Benefits explained: - Clear separation of content vs execution wrapper - Explicit return statement documents exports - Wrapping logic centralized in server.js - Consistent pattern across all global variable functions - Files clearly show their purpose (function bodies) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>