Laravel Dadata Laravel Package

Technical Evaluation

Architecture fit. This package is a thin Laravel service-provider wrapper around the DaData.RU HTTP API — it adds a config file, a facade/alias, and a client that maps Laravel config to DaData endpoints (address suggestions and normalization, counterparty/EGRUL lookup by INN, bank lookup by BIK, and similar reference-data calls). Architecturally it occupies the same slot as any third-party SDK: an outbound HTTP dependency behind a facade. That is compatible with a standard Laravel layered design, but the facade is a service-locator-shaped seam, not a domain interface. If address or counterparty data is core to the product (checkout, onboarding, KYC, invoicing), the facade boundary is too coarse to test against and too vendor-specific to swap. It fits cleanly only as an implementation detail behind our own AddressNormalizer / CounterpartyLookup contracts.

Integration feasibility. Mechanically trivial: composer require, publish config, set the API token in .env, resolve the facade. A competent Laravel developer is productive in under a day. The real feasibility question is not "can we call it" but "can we depend on it" — and the metadata says no: 0 stars, 0 dependents, score 0. This is an unvalidated personal package (teleport-kirov) whose repository name references another author's project (Pavel-Vinogradov/laravel-dadata-master), which strongly suggests a renamed fork or vendored copy with no community review, no dependents exercising it, and no upstream relationship we can verify. There is no evidence of CI, test coverage, semver discipline, or a maintainer with a support commitment.

Technical risk. Ranked by severity:

• Abandonment / provenance (high). Zero dependents means zero external bug-finding. A fork with no stated divergence from upstream means we cannot tell whether fixes will ever land. We should assume we own the code the day we adopt it.
• Version drift (high). No visible evidence of Laravel/PHP constraint breadth (e.g. illuminate/support ^8|^9|^10|^11). A single major-version pin will block our framework upgrade path and turn a two-line dependency into a fork-maintenance task at the worst possible moment.
• Silent API coupling (medium). Thin wrappers typically pass DaData response payloads through largely untyped. DaData has revised response shapes and added fields over time; untyped pass-through means schema changes surface as runtime undefined index errors in our domain code, not as contract failures.
• Secret handling (medium). Config-file-plus-.env token handling is standard, but confirm the package does not log request URLs with the token, does not cache responses to disk containing PII, and supports separate tokens per environment.
• Commercial and legal (medium). DaData is a metered, paid API with a limited free tier. Per-request cost is a product decision (suggestions fire on keystroke), and the data is Russian-registry data subject to 152-FZ residency and processing constraints — our own compliance posture, not the package's, but the package must not undermine it (e.g. by shipping a default endpoint we cannot audit).

Key questions for the maintainer / spike.

1. What is the divergence from Pavel-Vinogradov/laravel-dadata-master, and is this repo intended to track upstream?
2. Which Laravel and PHP versions are actually tested, and is there a CI matrix?
3. What license applies, and does it survive our redistribution/forking?
4. Does the client expose typed response objects or raw arrays? Is there a retry/timeout policy?
5. Is there built-in caching for reference data (banks, OKVED) that is effectively static?
6. How are token rotation and per-environment credentials handled?
7. Is there any published API-version pinning, or does the client call unversioned endpoints?

Integration Approach

Stack fit. Good on paper: it is a Laravel-native package, so it drops into an existing Laravel service with no new runtime, no sidecar, no queue infrastructure. If the consuming service is not Laravel (Symfony, a Node storefront, a Python data job), this package is irrelevant and we should call the DaData REST API directly — that is the single most important scoping decision, and it should be made before any evaluation effort is spent.

Migration path. Do not integrate the facade into domain code. Adopt in this order:

1. Vendor-isolate. Define our own interfaces (AddressSuggestions, AddressNormalize, CounterpartyByInn, BankByBik) in the domain layer. The package becomes the implementation of exactly one adapter class.
2. Pin and freeze. Require an exact version ("teleport-kirov/laravel-dadata": "x.y.z", not ^x.y). Given zero dependents, allow no implicit upgrades.
3. Own the source. If the license permits, vendor the package into our monorepo or mirror it to our own VCS so a Packagist deletion or repo takedown cannot break our build. This is the concrete mitigation for the abandonment risk and costs a few hours.
4. Contract-test the adapter. Record real DaData fixtures (success, empty result, 4xx, 5xx, malformed) and assert our adapter's behavior against them. This is what converts "thin wrapper" from a liability into a swappable detail.

Compatibility. Verify composer.json constraints against our current and next Laravel major before committing; if the constraint is narrow, budget the fork now rather than at upgrade time. Confirm auto-discovery registers cleanly and that the facade alias does not collide with an existing alias. Confirm the package does not pin an outdated Guzzle major that conflicts with the rest of the application's dependency graph — a classic failure mode for small wrapper packages.

Sequencing. Ship in value order, each independently shippable and independently revertible:

1. Spike (1–2 days). Sandbox token, one real call per endpoint, capture latency and payloads, confirm licensing and divergence from upstream.
2. Address normalization (server-side, on form submit) — highest value, lowest volume, immediately observable quality win.
3. Reference-data lookups (banks by BIK, OKVED) — static data, cache aggressively, near-zero marginal cost.
4. Counterparty/INN lookup — only if onboarding or invoicing requires it; carries the most compliance weight.
5. Suggestions (per-keystroke) — last, because it is the cost and rate-limit driver; implement behind a debounce and a server-side proxy, never with the DaData token in the browser.

Operational Impact

Maintenance. Treat this as unmaintained code we are adopting, not a dependency we are consuming. Budget: a half-day per quarter to review upstream/DaData API changes, plus a defined owner. If the license blocks vendoring, maintenance cost rises materially because we would be patching a third-party repo via a Composer patch plugin — an acceptable stopgap, a poor steady state.

Support. Support for the package is effectively zero: no dependents, no issue traffic, no stated maintainer commitment. Support for the API comes from DaData and is generally responsive commercial support, which is the part that matters — our failure modes will almost always be API-side, not wrapper-side. Escalation path must be to DaData, not to GitHub.

Scaling. The package itself does not scale; the API contract does. Three cost/latency drivers to design around:

• Per-request billing. Suggestions on keystroke are the dominant cost. Debounce (≥300ms), minimum input length (≥3 chars), server-side proxy with per-session rate limiting, and a hard monthly quota alarm.
• Rate limits. Implement queueing with backoff and a circuit breaker. Bulk standardization (e.g. backfilling 200k addresses) must go through a throttled job pipeline, not a request handler.
• Effective-static data. Bank/OKVED/reference lookups should hit our cache with a long TTL; the call only needs to happen on a miss. This can remove most of the steady-state volume.

Failure modes and mitigations.

• DaData unavailable or slow → timeouts must be short (1–2s), the circuit breaker must open, and the product must degrade to free-text address entry rather than blocking checkout or onboarding. Test this path deliberately; the default behavior of a naive wrapper is to surface a 500.
• Quota exhausted / billing lapse → the API returns errors indistinguishable to users from an outage. Add a quota metric and an alert at 80%, and a kill switch to disable remote lookups per feature flag.
• Token leak → never expose the token client-side; rotate on a schedule; confirm the package does not log full request URIs.
• Silent data-quality regression → DaData can return a "successful" but unnormalized result. Log the qc/quality codes on normalized addresses and alert on the ratio shifting; otherwise bad addresses enter the database invisibly and surface months later as failed deliveries or rejected invoices.
• Schema drift → the contract fixtures from the integration step are the detector. Without them, drift reaches production.
• Framework upgrade breakage → exact version pin plus vendored source means the breakage is a known, scheduled task rather than a blocked release.

Ramp-up. Low for developers (~half a day to first call, ~2 days to a production-grade adapter with caching, breaker, and fixtures). The non-obvious ramp-up is product and compliance: someone must own the per-request cost model, the 152-FZ data-residency position, and the "what does the user see when DaData is down" decision. That is the real gating item, and it is not solved by the package.

Recommendation. Approve as a narrow, vendored, interface-hidden adapter for address normalization and reference lookups in the Laravel service, contingent on license verification, Laravel-version confirmation, and a successful sandbox spike. Reject it as a general-purpose DaData SDK, as a frontend suggestion backend, and as anything the domain layer can see. The score 0 is not disqualifying for a 300-line wrapper — but it does mean the wrapper is the least valuable part of the dependency and the cheapest part to replace.