Serwersmsbundle Laravel Package

Technical Evaluation

Framing correction up front. The artifact is serwersms/serwersmsbundle, a Symfony bundle (declared support: Symfony 2, 3, 4), not a Laravel package. It has no service provider, no facade, no publishable config, and no Illuminate coupling — Symfony bundles are discovered through AppKernel/bundles.php and wired via DependencyInjection\Extension plus YAML service definitions. None of that wiring transfers to Laravel. The only reusable asset is the underlying SerwerSMS API v2 client code and the endpoint/payload knowledge it encodes.

Architecture fit — poor as a dependency, adequate as a reference. SMS delivery is an outbound side-effect adapter: exactly the kind of thing that should sit behind a narrow, swappable interface (SmsGateway::send(...)). This bundle instead exposes a concrete provider-bound service, so adopting it would couple your domain code to SerwerSMS with no seam for a fallback provider, no test double boundary, and no cost/segment abstraction. For a TPM, that is the central architectural objection — the package adds coupling without adding capability.

Integration feasibility — technically trivial, legally/version-wise blocked. Wrapping the vendor client in a ~150–300 line Laravel service provider is a 1–2 day job. The blocker is the dependency graph, not the code: a 2019-05-27 release predates PHP 7.4/8.x support and almost certainly pins php: ^5.6|^7.0 plus an older Guzzle. Laravel 9 requires PHP 8.0, Laravel 10 requires 8.1, Laravel 11 requires 8.2. Composer will refuse the install or the code will emit deprecations/fatals on 8.x. That alone ends the "adopt the bundle" path.

Technical risk — high and concentrated.

• Abandonment: last release 2019, 2 stars, 0 dependents. No downstream canary, no security triage, no CVE feed, effectively no code review by anyone but the author.
• EOL substrate: Symfony 4 reached end of life in November 2023; the bundle never moved to Symfony 5/6/7, which signals the maintainer is inactive.
• API drift: the package is bound to SerwerSMS API v2. Whether v2 is still the current/contracted version, and its deprecation horizon, is unknown and is the single largest unquantified risk.
• Credential handling: bundles of this era typically take username/password in YAML with no rotation, no per-tenant scoping, and no secret-manager integration — a poor fit for a Laravel app that should read from env/Vault.
• No abstraction: no interface, no DLR/webhook ingestion, no idempotency key, no retry/backoff policy. Any of those becomes your code anyway.

Key questions to close before any decision.

1. What are the exact composer.json constraints — PHP, Guzzle, symfony/*? Does a --ignore-platform-reqs install actually run on PHP 8.2?
2. Is the plain PHP client (serwersms/php-client or equivalent) published and maintained separately? That is the only component worth reusing.
3. Is API v2 still supported by SerwerSMS, and what is its published deprecation/sunset policy? Is there a v3?
4. Does the provider expose delivery reports via webhook or polling, and is that surfaced anywhere in this code?
5. Is there a paid support or SLA path from SerwerSMS for the API (not the bundle)?
6. Rate limits, per-segment pricing, sender-name/prefix registration rules for Poland, and GDPR data-processing terms.
7. Who is the maintainer, and is there a stated response commitment? (Assume no.)

Verdict: Do not adopt as a production dependency. Treat the repository as API v2 documentation and build a native adapter. Score the opportunity low (~2/10) on maintenance and fit; moderate on "cheap to reimplement," which is the actual takeaway.

Integration Approach

Stack fit. If the target is Laravel (8+), the recommended shape is:

• App\Contracts\SmsGateway — one method plus a SmsResult value object (message id, segments, cost, provider status).
• App\Services\Sms\SerwerSmsGateway — implements the contract using Laravel's Http facade against API v2 endpoints. ~200 lines, no third-party dependency.
• App\Providers\SmsServiceProvider — binds the contract to the implementation from config/sms.php.
• config/sms.php — driver, username, password, sender, format, timeout, retry, all sourced from env().
• app/Jobs/SendSms.php — queued, $tries = 3, exponential backoff, failed() handler that alerts.

If you insist on reusing the vendor SDK, install it via a VCS composer repository pinned to a specific commit, add platform constraints yourself, and wrap it behind the same contract so it can be swapped in a day.

Migration path (works whether or not you ever touch the bundle).

1. Spike (0.5 day): read the bundle source; extract the auth handshake, base URL, endpoint paths, request body shape, and error-code table. Record it in an internal ADR.
2. Sandbox validation (0.5 day): hit the provider's test endpoint with a real request; confirm credentials, sender name, and response schema. Confirm Polish diacritics encoding (GSM-7 vs UCS-2) because that determines segment count and cost.
3. Adapter build (2 days): contract, implementation, config, provider binding, unit tests against Http::fake().
4. Delivery hardening (1 day): queue job, retry/backoff, idempotency key derived from your internal notification ID, structured logging with correlation id.
5. DLR ingestion (1 day): webhook route (CSRF-exempt, signature/IP allow-listed) updating message status.
6. Dual-run (1 week): send internal/non-critical traffic only; compare delivery rates and segment counts before touching OTP or transactional customer messages.

Compatibility. Target PHP 8.2/8.3 and the Laravel version you already run; verify the provider client supports TLS 1.2+, HTTP/2, and a configurable timeout. If the app is on Symfony 5.4/6/7 instead, the same guidance applies: skip the bundle, register the SDK as a service manually. In both cases, pin and own the transport.

Sequencing rationale. Build the interface first even though there is only one provider. Provider-swapping in SMS is a real, recurring event (pricing changes, deliverability, regulatory), and the interface is the only cheap insurance available here. Do not migrate an existing working integration onto this bundle under any circumstances — the migration has downside and no upside.

Operational Impact

Maintenance — you will own it. Fork-and-own is the realistic outcome: expect to maintain a vendored copy or a from-scratch adapter. Budget roughly 1–3 engineer-days per year for routine dependency and API-shape upkeep, plus a hard fork event if SerwerSMS changes API versions. This is not a "install and forget" dependency; it is a code snippet with a composer.json.

Support. There is no support contract for the bundle. SerwerSMS's support covers the HTTP API — authentication failures, account limits, sender-name registration, delivery reports — not this Symfony wrapper. Escalation for bugs in the wrapper terminates at a GitHub issue on a repository with 2 stars.

Scaling. Volume is bounded by the provider's rate limits and your budget, not by your infrastructure. Two operational realities:

• Synchronous calls are a latency and availability liability. Never call the provider inline in a request path. Queue everything; the queue worker is your throttle and your buffer.
• Billing is per segment. A single Polish diacritic can push a message from GSM-7 into UCS-2 and cut characters-per-segment roughly in half. Instrument segments-per-message and cost-per-day from day one; this is the most common silent cost regression in SMS integrations and no library-level abstraction in this package protects you from it.

Failure modes to design against.

• Provider 5xx/timeout → retry with backoff and a dead-letter path; never retry blindly without an idempotency key or you will double-send and double-bill.
• HTTP 200 with an error body → the classic SMS API trap; parse the payload's status field, not the HTTP code.
• Credential expiry or account suspension → a liveness probe (periodic internal alert to an ops phone) catches this before a customer-facing OTP does.
• DLR webhook loss → reconciliation job polling status for messages stuck in sent.
• Number normalization → validate and E.164-normalize before handoff; malformed numbers are billed and rejected.
• Duplicate sends from job re-queues after worker restarts.

Compliance. Phone numbers are personal data under GDPR. A Polish provider is a positive on EU data residency, but you still need a data-processing agreement, a retention policy for message bodies and numbers, and — for marketing traffic — documented consent under Polish electronic-communications rules. Marketing and transactional traffic should be separable in config so consent enforcement is not a code change.

Ramp-up. Low. A Laravel developer reaches first-send in under a day using the bundle as a spec. The learning cost is negligible; the risk is entirely in the absence of maintained code, tests, and observability scaffolding — all of which you supply.

Instrumentation to ship with v1: send latency p50/p95, provider error rate by code, DLR delivery rate, segments per message, spend per day, queue depth and dead-letter count. If those six metrics exist, this integration is operationally safe regardless of which client library sits underneath it.