feat: provider plugin architecture + Netlify adapter

[seanspeaks]

Summary

• Netlify adapter (`@friggframework/netlify-adapter`): split Netlify Functions for auth, user, health, admin, docs, webhooks, integration routes, background worker, scheduled sync
• Queue provider abstraction: factory switching between SQS, Netlify Background, and QStash
• Scheduler abstraction: Netlify scheduled function adapter
• Provider plugin architecture plan (`plan.md`): consistent plugin shape for all deployment targets

Code changes

• `packages/devtools/netlify-adapter/` — complete Netlify deployment adapter
• `packages/core/queues/providers/` — Netlify Background + QStash queue adapters
• `packages/core/queues/queue-provider-factory.js` — multi-provider queue factory
• `packages/core/infrastructure/scheduler/netlify-scheduler-adapter.js`

Architecture plan (plan.md)

• Provider plugin interface (what every `provider-*` must export)
• Mapping tables: Netlify (~80% done), AWS (extract from core), Vercel, GCP, Docker/local
• Database plugin interface (`database-postgres`, `database-mongodb`)
• Deploy story + difficulty assessment + 8-phase roadmap

Test plan

• Existing tests pass
• Netlify adapter generates valid netlify.toml
• Queue provider factory selects correct provider

📦 Published PR as canary version: 2.0.0--canary.545.676b219.0

✨ Test out this PR locally via:

npm install @friggframework/admin-scripts@2.0.0--canary.545.676b219.0
npm install @friggframework/ai-agents@2.0.0--canary.545.676b219.0
npm install @friggframework/core@2.0.0--canary.545.676b219.0
npm install @friggframework/devtools@2.0.0--canary.545.676b219.0
npm install @friggframework/e2e@2.0.0--canary.545.676b219.0
npm install @friggframework/eslint-config@2.0.0--canary.545.676b219.0
npm install @friggframework/prettier-config@2.0.0--canary.545.676b219.0
npm install @friggframework/provider-aws@2.0.0--canary.545.676b219.0
npm install @friggframework/provider-netlify@2.0.0--canary.545.676b219.0
npm install @friggframework/schemas@2.0.0--canary.545.676b219.0
npm install @friggframework/serverless-plugin@2.0.0--canary.545.676b219.0
npm install @friggframework/test@2.0.0--canary.545.676b219.0
npm install @friggframework/ui@2.0.0--canary.545.676b219.0
# or 
yarn add @friggframework/admin-scripts@2.0.0--canary.545.676b219.0
yarn add @friggframework/ai-agents@2.0.0--canary.545.676b219.0
yarn add @friggframework/core@2.0.0--canary.545.676b219.0
yarn add @friggframework/devtools@2.0.0--canary.545.676b219.0
yarn add @friggframework/e2e@2.0.0--canary.545.676b219.0
yarn add @friggframework/eslint-config@2.0.0--canary.545.676b219.0
yarn add @friggframework/prettier-config@2.0.0--canary.545.676b219.0
yarn add @friggframework/provider-aws@2.0.0--canary.545.676b219.0
yarn add @friggframework/provider-netlify@2.0.0--canary.545.676b219.0
yarn add @friggframework/schemas@2.0.0--canary.545.676b219.0
yarn add @friggframework/serverless-plugin@2.0.0--canary.545.676b219.0
yarn add @friggframework/test@2.0.0--canary.545.676b219.0
yarn add @friggframework/ui@2.0.0--canary.545.676b219.0

---

Note

High Risk
High risk because this introduces breaking API/initialization changes (explicit adapter injection) and restructures core/provider dependencies, which can cause runtime failures if consumers miss wiring or rely on removed mongoose/AWS imports.

Overview
Adds formal multi-provider architecture documentation via new ADRs, including a breaking plan to move AWS SDK usage out of @friggframework/core and a standard provider plugin interface.

Implements the decoupling by updating core components (notably Worker) to be provider-agnostic and require injected adapters (e.g., queueClient) instead of importing AWS SDKs directly, and updates tests to use injected mocks rather than AWS SDK mocks.

Cleans up core dependencies by removing mongoose-specific assertion/model code, replacing lodash.get with an internal deepGet, and adjusting repository factories to lazily require() DB-specific adapters only when selected. Monorepo/workspace config is updated to include packages/providers/*, adds new @friggframework/provider-aws and @friggframework/provider-netlify packages, and refreshes lockfile dependencies (including AWS SDK version bumps and supertest upgrade).

^{Written by Cursor Bugbot for commit dba001a. This will update automatically on new commits. Configure here.}

In general, to fix a permissive CORS configuration you should avoid origin: '*' (especially with credentials: true) and instead either (a) disable CORS when not needed, or (b) explicitly whitelist allowed origins, typically via a list that can come from configuration. You should also avoid other wildcard settings like allowedHeaders: '*' and methods: '*' when you know the specific headers and methods you expect.

For this file, the least intrusive, robust fix is to (1) introduce a small whitelist-based origin function that reads allowed origins from an environment variable (or uses a safe default of no cross-origin access), and (2) replace the wildcard origin, allowedHeaders, and methods with explicit, commonly used values. That preserves functionality for allowed origins while removing the blanket '*'. Specifically:

• Add a helper getCorsOrigin that reads process.env.ALLOWED_CORS_ORIGINS (comma-separated list), trims the entries, and returns a function (origin, callback) compatible with the cors package. If no env var is set, default to false (CORS disabled).
• Use that helper in the cors options: origin: getCorsOrigin().
• Replace allowedHeaders: '*' and methods: '*' with explicit lists such as ['Content-Type', 'Authorization', 'X-Requested-With'] and ['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'OPTIONS']. This is restrictive enough to address the warning but broad enough to avoid breaking typical API clients.

All changes occur inside packages/devtools/netlify-adapter/lib/create-netlify-app-handler.js, near the top where the app and CORS middleware are defined.

[graphite-app]

The which command is Unix-specific and will fail on Windows systems, breaking the preflight check.

Impact: Deployment will fail on Windows with 'which' is not recognized as an internal or external command.

Fix:

function isCommandAvailable(command) {
    try {
        const cmd = process.platform === 'win32' ? 'where' : 'which';
        execSync(`${cmd} ${command}`, { stdio: 'ignore' });
        return true;
    } catch {
        return false;
    }
}

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.

[graphite-app]

Queue provider defaults to SQS when no arguments are passed, which will fail on Netlify. The createQueueProvider() factory defaults to QUEUE_PROVIDERS.SQS when no provider is specified (see queue-provider-factory.js line 50). This Netlify-specific function should explicitly specify the queue provider:

const queueProvider = createQueueProvider({
    provider: 'netlify-background'
});

Or load from app definition:

const { queue } = loadAppDefinition();
const queueProvider = createQueueProvider({
    appDefinition: { queue }
});

Without this fix, the function will attempt to instantiate SqsQueueProvider which requires AWS SDK and credentials, causing failures in Netlify's runtime.

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.

[graphite-app]

Queue provider defaults to SQS when no arguments are passed, which will fail on Netlify. The createQueueProvider() factory defaults to QUEUE_PROVIDERS.SQS when no provider is specified (see queue-provider-factory.js line 50). This Netlify-specific worker should explicitly specify the queue provider:

const queueProvider = createQueueProvider({
    provider: 'netlify-background'
});

Or load from app definition:

const { queue } = loadAppDefinition();
const queueProvider = createQueueProvider({
    appDefinition: { queue }
});

Without this fix, the function will attempt to instantiate SqsQueueProvider which requires AWS SDK and credentials, causing failures when parsing events in Netlify's runtime.

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.

[graphite-app]

Race condition: If queueProvider.send() succeeds but repository.delete() fails (database error, network timeout, etc.), the schedule remains in the database with state='PENDING' and will be re-dispatched on the next cron run, causing duplicate job execution.

Fix: Update the schedule state to 'PROCESSING' before dispatching, then delete after success:

for (const schedule of dueSchedules) {
    try {
        // Mark as processing first
        await this.repository.save({
            ...schedule,
            state: 'PROCESSING'
        });
        
        if (this.queueProvider) {
            await this.queueProvider.send(
                schedule.payload,
                schedule.queueResourceId
            );
        }
        
        // Only delete after successful dispatch
        await this.repository.delete(schedule.scheduleName);
        processed++;
    } catch (error) {
        // Update state to FAILED instead of deleting
        await this.repository.save({
            ...schedule,
            state: 'FAILED'
        }).catch(() => {});
        errors++;
    }
}

Spotted by Graphite



Is this helpful? React 👍 or 👎 to let us know.

[cursor]

Custom deepGet doesn't support bracket notation paths

Medium Severity

The custom deepGet function replacing lodash.get only splits paths on . (dots), so it doesn't handle bracket notation like 'a[0].b' or 'items[2].name'. lodash.get supported both 'a.b.c' and 'a[0].b' path formats. Any caller using bracket notation will silently get undefined instead of the expected value, since 'a[0]' becomes a single key lookup rather than indexing into an array.

 

[cursor]

getAll treats falsy values as missing keys

Low Severity

In getAll, the check if (val) treats legitimate falsy values like 0, false, and '' as missing keys. This existed before with lodash.get but is worth noting since this function is being touched — the replacement deepGet now correctly returns these falsy values, but getAll discards them and reports them as missing, potentially throwing spurious errors.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Lazy require with const in switch cases lacks block scoping

Low Severity

Using const declarations inside switch case blocks without wrapping each case in curly braces means all declarations share the switch block's scope. While this works here because each variable name is unique and each case returns, it's fragile — a future refactor adding another case with a similarly-named destructured variable would cause a runtime SyntaxError. This pattern is repeated across all four repository factory files.

Additional Locations (2)

• packages/core/admin-scripts/repositories/admin-process-repository-factory.js#L24-L34
• packages/core/admin-scripts/repositories/script-execution-repository-factory.js#L26-L36

 

[cursor]

Circular dependency risk in config.js via loadAppDefinition

Medium Severity

getDatabaseType() now calls loadAppDefinition() from ../handlers/app-definition-loader. If app-definition-loader (or anything in its require chain) imports from ../../database/config — directly or transitively — this creates a circular dependency that may cause loadAppDefinition to be undefined at call time. The previous implementation used direct fs/path operations with no framework imports, avoiding this risk entirely.

 

[cursor]

You have run out of free Bugbot PR reviews for this billing cycle. This will reset on April 9.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3 Security Hotspots
5.7% Duplication on New Code (required ≤ 3%)
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE