Df Aws Laravel Package

Product Decisions This Supports

• Build vs. buy the API tier. df-aws is a DreamFactory connector, not a standalone library. Its value is pairing the AWS SDK for PHP with DreamFactory's governance layer — role/API-key auth, per-endpoint rate limits, request logging, and generated OpenAPI docs — so a team can expose S3, DynamoDB, SQS/SNS or Lambda resources as governed REST endpoints instead of hand-writing controllers or Lambda+API Gateway glue. Decide whether that governance bundle is worth adopting the platform versus a ~200-line Laravel controller per data source.
• Gateway standardization. Roadmap question: is DreamFactory the sanctioned self-hosted API gateway for AWS-backed data, or is the org going cloud-native (API Gateway, AppSync, Cognito)? This package only makes sense in the first world; it is a commitment to a runtime, not just a dependency.
• Data access for LLM/agent features. The stated positioning — governed access for "enterprise apps and local LLMs" — maps to a concrete use case: giving RAG pipelines or self-hosted model tool-calling scoped, auditable access to S3 documents or DynamoDB tables per tenant, without handing out raw IAM credentials. Worth a spike if that's on the roadmap; not worth it if you're already standardized on a vector store and object-store presigned URLs.
• Regulated / air-gapped deployments. Where cloud-native managed gateways are disallowed, contractually awkward, or operationally immature, a self-hosted connector with audit logging is a defensible architectural choice — and a differentiator in enterprise deals.
• Time-to-market for internal tools. For a 1–3 engineer team, this can compress "expose internal AWS data with auth and logs" from weeks to days. Size that saving honestly against onboarding cost and platform lock-in.
• Do not treat this as a standalone adoption decision. With 2 stars and 0 dependents, this is vendor-maintained infrastructure, not community-vetted. The real decision is "adopt DreamFactory," and df-aws rides along.

When to Consider This Package

Adopt when most of the following hold:

• DreamFactory is already deployed — the marginal cost is a Composer require and config, not a platform migration.
• You need governed access (auth, per-consumer keys, rate limits, audit trail, generated docs) to one or more AWS services, and rebuilding that layer is genuinely out of scope.
• Your deployment is self-hosted or on-prem, or compliance requires it.
• Request volumes are moderate and internal-facing — admin tools, back-office integrations, batch jobs, agent tool calls. PHP's request lifecycle is not where you want a high-QPS hot path.
• Your AWS surface is broad enough that hand-rolled endpoints would multiply (several services, several consumers, several roles).
• You can pin a version and accept vendor-dependent maintenance, ideally with a commercial support path.

Look elsewhere when:

• You are not already running DreamFactory. The governance layer is the entire justification; the AWS SDK wrapper alone is not.
• The need is one S3 bucket or one table. Presigned URLs, DynamoDB SDK calls from a service, or a single Laravel controller will be cheaper and clearer.
• Latency, throughput, streaming, or binary-heavy workloads dominate — that's a poor fit for this architecture.
• Your platform strategy is cloud-native: API Gateway + IAM/Cognito, AppSync, EventBridge, Step Functions already give you governance with less operational surface.
• You need community support, examples, or third-party integrations. Two stars and zero dependents means effectively no ecosystem; assume you are the first to hit most edge cases.
• The AWS services you need aren't confirmed in the connector's coverage — verify against your list before committing, and treat an uncovered service as a fork-or-build decision.

How to Pitch It (Stakeholders)

For executives: This is a connector that lets our self-hosted DreamFactory instance expose AWS data — object storage, tables, queues, functions — as governed APIs, reusing the platform's authentication, rate limiting, audit logging, and auto-generated documentation. The business case is not the connector itself; it's avoiding a bespoke integration layer per data source. Concretely: faster delivery of internal and partner-facing data APIs, a consistent audit trail for compliance, and a credible answer for "how do local models and internal apps get scoped access to enterprise data without sharing credentials." The risk to name openly: it is a small, vendor-maintained package (Apache-2.0, minimal public adoption), so we treat it as a dependency on DreamFactory the platform, pin versions, and keep a fork/support budget in the plan.

For engineering: It's a Composer package that registers an AWS service type inside DreamFactory, wrapping aws/aws-sdk-php so endpoints are auto-generated and then constrained by DreamFactory roles, API keys, and limits. No new infrastructure — it runs in the existing PHP process. What we get for free: OpenAPI generation, per-consumer keys, request logs. What we pay: an opinionated runtime, request-per-request overhead, and a thin maintenance base — so we own integration testing, we pin the version, and we confirm service coverage against our actual AWS list before we commit. Recommendation: two-day spike behind a feature flag, measuring coverage for our top three AWS services and the latency profile of a representative read/write, then decide.