Four Tochki Products Laravel Package

Technical Evaluation

Architecture fit. The package is labelled "Laravel/PHP" but its actual surface is Symfony-shaped. Every documented command — php bin/console baks:assets:install, doctrine:migrations:diff, doctrine:migrations:migrate, bin/phpunit --group=... — is a Symfony/BaksDev convention. A stock Laravel application has no bin/console, no baks:assets:install, and uses Eloquent migrations, not Doctrine's. Combined with the baks-dev namespace (a platform vendor, not a library vendor), the realistic reading is: this is a module of the BaksDev Symfony distribution for 4tochki's product domain, published to Packagist for that platform's consumers. Fit is therefore strong for a Symfony/BaksDev host, weak for a Laravel host, and workable as an isolated sidecar service.

Integration feasibility. composer require will resolve; whether the result is usable is a separate question. The README documents no configuration keys, no environment variables, no service IDs, no entity names, no HTTP endpoints, and no 4tochki API contract. The only external reference is a B2B warehouse-ID lookup page. The prior product and engineering assessments in this repo reference ProductSyncService, InventoryService, .env keys like FOURTOCHKI_PARTNER_ID, and traits like Syncable — none of these appear in the README or release notes. Treat all of them as hypotheses to be validated against vendor/baks-dev/four-tochki-products/src/, not as documented capability. The MIT license is the saving grace: source inspection is always available.

Technical risk.

Version numbering at 7.4.x with zero public adoption strongly suggests the version tracks the maintainer's internal platform, not semver obligations to outside consumers. Downstream, that means breaking changes can arrive in patch releases.

Key questions to answer before commitment.

1. Does the package require the BaksDev core kernel, or does it install standalone?
2. What HTTP transport does it use (Symfony HttpClient, Guzzle, PSR-18) and can it be swapped for the host's client?
3. Where do 4tochki credentials and warehouse IDs live — container parameters, env, or DB?
4. Is the package authoritative for product data, or a mirror/read-replica of 4tochki's catalog? What is the sync direction?
5. Does it provide idempotency keys or upsert semantics for batch writes?
6. What is the exact Symfony/Doctrine/Laravel compatibility matrix (composer why-not output against our pinned framework)?
7. What 4tochki API surface is covered — product CRUD, pricing, stock per warehouse, images, categories — and what is out of scope?
8. Which 4tochki API rate limits and failure codes are handled vs. surfaced raw?

Integration Approach

Stack fit decision. Run one decision gate before any engineering:

• Host is Symfony 6/7 + Doctrine → high fit. Treat as a normal bundle: install, run assets + migrations, wire config, done. Lowest cost path by an order of magnitude.
• Host is Laravel → do not install into the main application. Deploy the package inside a thin Symfony container (or a Laravel-adjacent PHP service) that exposes an internal HTTP/queue contract. Laravel remains the system of record; the sidecar owns the 4tochki dialect.
• Host is neither → evaluate whether the value is the API client or the domain model. If it is the client, port it; if it is the model, reconsider the vendor.

Migration path for a Laravel shop. Three options, ranked:

1. Sidecar service (recommended). Symfony container + the package + a small internal API. Isolates Doctrine, PHP 8.4, and the vendor's release cadence from the product monolith. Cost: one extra deployable, one extra contract to maintain.
2. Lift the client, keep Eloquent. Read the vendor source, extract the HTTP/auth/payload layer, re-implement persistence as Laravel models and migrations. Best long-term maintainability, highest up-front effort, and it forfeits upstream updates — which, given the release quality, may not be a real loss.
3. Doctrine-in-Laravel bridge. Technically possible, operationally poor. Only justified if the Doctrine entity graph is genuinely valuable and inseparable from the client.

Compatibility work. Confirm PHP 8.4 availability in the target runtime image, then run composer why-not baks-dev/four-tochki-products <version> against the pinned Symfony/Doctrine/Laravel set. Expect friction on doctrine/migrations and symfony/console. Pin the package with an exact version constraint and composer.lock commit; do not allow ^7.4.

Sequencing.

Gate each phase on the audit log producing clean data; do not parallelise phases 2–4.

Operational Impact

Maintenance. Assume you are the maintainer. Plan for an internal fork under our own namespace within the first quarter, with a documented upstream-merge policy. Because release notes carry no content, every upstream bump requires a source diff review — budget roughly half a day per upgrade, not the usual minutes. Assign a named owner; this package cannot be left ownerless.

Support. There is no community, no issue history of substance, and no vendor SLA. Support channels are (a) the internal team that read the source, and (b) the 4tochki B2B account relationship. Both must exist before go-live. Critically, retain a raw-API fallback: if the package breaks and the vendor is unresponsive, the team must be able to reach 4tochki's endpoints directly. That means credential custody and endpoint documentation must live with us, not only inside the library.

Scaling. Two ceilings, both unknown at evaluation time and both must be measured in the spike: 4tochki's API rate limits, and the package's batching behaviour. Never call the package synchronously from a web request — push all remote operations through a queue with per-warehouse concurrency limits and exponential backoff. Persist in a dedicated schema or connection so Doctrine migrations cannot touch the core product tables and so stock-volume growth does not contaminate primary DB sizing.

Failure modes to instrument.

• Credential or token expiry → silent auth failures; alert on first non-2xx.
• Warehouse-ID drift — the AvailableWarehouses list is a live external reference; a partner removing a warehouse invalidates a hardcoded config.
• Partial batch failure absent idempotency → duplicate SKUs in 4tochki. Verify replay safety explicitly.
• Rate-limit throttling presenting as generic errors; classify responses before alerting.
• Schema drift introduced by a patch-level upgrade.
• PHP 8.4 runtime absence on a host rebuilt from an older base image.
• Vendor abandonment: no releases, no security patches; requires our fork to be buildable standalone.
• Regulatory/payment friction on the Russian B2B side affecting data flows independent of the code.

Ramp-up. Russian-language documentation plus a thin README means onboarding cost is dominated by source reading, not reading docs. Estimate one engineer at 1–2 weeks to reach confident operation, plus a commerce/ops counterpart who owns SKU and warehouse data quality. Produce our own English README, config reference and runbook as the first deliverable of the spike — it is the artefact that makes the package supportable and de-risks the bus factor. Given the zero-adoption baseline, treat the whole engagement as a build-vs-buy decision already tilted toward "buy the source, own the integration," and price it accordingly.