Salesforce Bundle Laravel Package

Technical Evaluation

Verdict: do not adopt. Treat as design reference only.

The package is a Symfony2 bundle, not a Laravel package, despite the "Laravel/PHP" framing. Its value is architectural precedent, not deployable code.

• Architecture fit — none for a Laravel stack. xrow/salesforce-bundle is built on Symfony's bundle contract: a Bundle class, a DI Extension with a Configuration tree, service definitions in XML/YAML, and event-dispatcher hooks. Laravel consumes a handful of Symfony components (HttpFoundation, Console, Process), but has no bundle system, no container extension points of that shape, and no autoload path that would resolve the bundle's service wiring. Porting is a rewrite, not an integration. If the target is actually Symfony, the fit is still poor: the bundle targets Symfony 2.x, which reached end of life in November 2018.
• Integration feasibility — low. Last release 2015-05-06, roughly a decade old. Expect PHP 5.5/5.6-era syntax and composer.json constraints that hard-fail on PHP 8.2/8.3 and Composer 2. Zero stars, zero dependents, zero issue traffic means the code paths have not been exercised against any modern runtime. Beyond PHP: Salesforce retires API versions about three years after release, so any pinned 2015-era endpoint (v2x–v3x) returns 410/INVALID_VERSION today. The 2015-era auth pattern is almost certainly username + password + security token, which Salesforce disabled by default in 2021 and which many orgs will not re-enable.
• Technical risk — high if adopted, low if used as a spec. Three independent decay vectors compound: dead PHP runtime, dead Symfony major, dead Salesforce API version. A naive composer require will either fail resolution outright or, worse, succeed in an isolated legacy environment and lock the team to an unsupportable stack. Supply-chain risk is unmanaged: no security advisories, no CVE monitoring, and any transitive dependencies are equally abandoned.
• Signal quality. 0 stars / 0 dependents / 8-year-old release is not a "small but stable" library — it is unexercised. There is no user base to surface bugs, no maintainer to answer questions, and no evidence the Salesforce side was ever validated beyond the author's own org.

Key questions to resolve before any build decision:

1. Is the target runtime Laravel or Symfony? The answer changes the build entirely — and neither answer makes this package viable.
2. Which Salesforce surface do we need: REST, Bulk API 2.0, SOAP/Partner WSDL, Platform Events, or GraphQL? Bulk 2.0 in particular did not exist in 2015.
3. Which auth flow does the target org permit — OAuth 2.0 JWT bearer (server-to-server), web-server flow with refresh tokens, or is legacy password flow still enabled?
4. What object/volume profile: records per day, write vs. read ratio, tolerance for eventual consistency?
5. What is the org's daily API request allocation, and who owns the Salesforce admin relationship and sandbox access?
6. Who owns the fork if we reuse anything, and what is the standing maintenance budget?

Integration Approach

Recommendation: do not add this package to composer.json in either stack. Extract intent from the bundle (object/field mapping conventions, config shape) and implement against a current client.

Path A — Laravel target. No bundle path exists. Build a thin adapter: a SalesforceClient interface with query(), find(), create(), update(), upsert(), bulkIngest(), bound to a concrete implementation over Laravel's Http client with an OAuth 2.0 token manager. This is a few hundred lines and fully owned. Evaluate maintained alternatives (e.g. omniphx/forrest) as a starting reference, but keep the interface boundary so the transport is swappable.

Path B — Symfony 6.4/7.x target. Still no drop-in. Either a maintained SOAP client (phpforce/soap-client) if the requirement is genuinely SOAP, or the same REST adapter built on symfony/http-client. Do not fork the bundle; the fork cost exceeds the rewrite cost.

Compatibility baseline to design against: PHP 8.2+, Composer 2, Laravel 10/11 or Symfony 6.4/7.x, Salesforce API at or near the current stable version, OAuth 2.0 JWT bearer for server-to-server or web-server flow with refresh tokens.

Suggested sequencing:

1. Spike (1–2 weeks). Prove auth against a sandbox and execute one SOQL query. This is the only genuinely uncertain step; everything after is engineering.
2. Read-only sync of one object. Establish the mapping layer and the scheduler. No writes.
3. Write path with idempotency. Use external IDs and upsert so retries cannot duplicate records.
4. Volume path. Move batch workloads to Bulk API 2.0; per-record REST will not survive volume.
5. Resilience. Retry with backoff, dead-letter queue, structured logging of Salesforce error codes, and a reconciliation job.
6. Retire the bundle as a reference artifact and document the mapping decisions it informed.

Operational Impact

• Maintenance — the dominant cost. If any code is reused, the team inherits ownership permanently. Salesforce ships three releases a year and retires API versions on a ~three-year clock, so "done" is never true. Budget a standing maintenance line (roughly 2–5 days/month for a single-object integration, spiking around Salesforce release windows and PHP upgrades) rather than a one-off project cost.
• Support — effectively none. No vendor, no SLA, no issue tracker activity, and no community to search. Every defect is first-principles debugging. Escalation path is "the one engineer who touched it."
• Scaling — bounded by the org, not the code. Design against Salesforce's daily API request allocation (commonly 15,000/day on Enterprise, materially higher on Unlimited), the concurrent long-running request cap (~10), and Bulk API 2.0 for anything batch-shaped. Per-record REST loops and per-request token refreshes are the two most common ways these integrations fall over at month-end. Cache reference data; do not query it per request.
• Failure modes to instrument explicitly:
  • Token expiry or credential rotation, presenting as a hard outage rather than a transient error.
  • API version retirement returning 410/INVALID_VERSION on a previously working deployment.
  • REQUEST_LIMIT_EXCEEDED under volume — needs backoff and queueing, not retry-storming.
  • Field-level security, validation rules, and required-field changes made by admins in production without notice, causing partial write failures.
  • Metadata drift as objects and picklists change; the mapping layer must fail loudly, not silently drop fields.
  • Silent data loss when errors are swallowed by a queue worker — a reconciliation job is not optional.
  • IP restrictions or connected-app policy changes on the Salesforce side that invalidate the integration without any code change.
• Ramp-up. The Salesforce domain knowledge (auth flows, API limits, object model, sandbox workflow) is the real onboarding cost, not the package. Plan 1–2 weeks for an engineer to reach a working spike, 4–8 weeks for a production-grade single-object integration with writes and resilience, and require sandbox plus Salesforce admin access from day one. Assume no knowledge transfer from the bundle itself — its documentation surface is a 2015 README.