Client Laravel Package

Product Decisions This Supports

• High-Performance Real-Time Data Access: Enables seamless integration with Tarantool (a high-performance NoSQL database) for low-latency, high-throughput applications (e.g., gaming backends, ad-tech, financial systems). Justifies build vs. buy for teams already using Tarantool.
• Microservices & Event-Driven Architectures: Supports event sourcing, CQRS, or pub/sub patterns via Tarantool’s Lua scripting + PHP middleware (e.g., retry logic, auth, logging).
• Legacy System Modernization: Bridges PHP monoliths with Tarantool’s in-memory speed without rewriting core logic (e.g., migrating from MySQL to Tarantool for session storage).
• Roadmap for Data Layer Abstraction: Foundation for a unified data client (e.g., abstracting Tarantool, Redis, or PostgreSQL under a single interface).
• Cost Optimization: Reduces infrastructure costs by leveraging Tarantool’s single-threaded, high-concurrency model for read-heavy workloads (vs. scaling PostgreSQL shards).
• Platform Upgrade Planning (v0.11.0): The new release drops PHP 7.x and PHP 8.0–8.1 and requires PHP 8.2+. This is now a hard input into our PHP runtime roadmap — any service adopting or upgrading this client must be on PHP 8.2+ first. Treat it as a dependency-driven upgrade item, not a discretionary one.

When to Consider This Package

• Version requirements (v0.11.0):
  • Requires PHP 8.2 or newer — no support for PHP 7.x or PHP 8.0–8.1.
  • Requires rybakit/msgpack >= 0.11.2; check for conflicts with packages pinning older versions.
  • The release adds native parameter and property types enforced at runtime, so loosely-typed call sites (passing strings where ints are declared, etc.) may now throw where they previously worked.
• Avoid if:
  • Your stack is 100% JavaScript/Node.js (use node-tarantool instead).
  • You are pinned to PHP < 8.2 (shared hosting, legacy LTS platforms, or a monolith not yet upgraded) — stay on v0.10.1 and plan the runtime upgrade before adopting v0.11.x.
  • You need full SQL compliance (Tarantool’s SQL is limited; use PostgreSQL for ANSI SQL).
  • Your team lacks PHP/Lua expertise (steep learning curve for Tarantool’s data model).
  • You require multi-region replication (Tarantool’s replication is regional; use CockroachDB for global sync).
• Consider alternatives:
  • For pure PHP: Use predis (Redis) or doctrine/dbal (PostgreSQL) if Tarantool isn’t a hard requirement.
  • For polyglot persistence: Evaluate Apache Ignite or ScyllaDB (Cassandra-compatible) if you need both SQL and NoSQL.
  • For managed services: Use Tarantool Cloud if you want to offload infrastructure management.

How to Pitch It (Stakeholders)

Executives

*"This PHP client unlocks Tarantool’s in-memory speed for our high-scale services (e.g., real-time analytics, gaming leaderboards) while keeping our PHP stack intact. By integrating this, we can:

• Cut latency from ~10ms (PostgreSQL) to <1ms for read-heavy workloads.
• Reduce cloud costs by 30–50% vs. scaling PostgreSQL shards.
• Future-proof our data layer for event-driven architectures (e.g., Kafka + Tarantool for event sourcing).

What changed in v0.11.0: the library now requires PHP 8.2+ and drops older runtimes. This is a maintenance-health signal — the maintainers are actively shipping, modernizing the codebase, and testing against current PHP versions (8.2–8.5). The cost is a prerequisite: any target service must already be on PHP 8.2+, which should be sequenced into our existing runtime upgrade work rather than treated as new scope.

Risk: Minimal—Tarantool is battle-tested at scale (used by Mail.ru, Yandex, and VK), and this release is a typing/tooling modernization rather than a protocol change. We’ll pilot with [X] service first, on a PHP 8.2+ runtime."*

Engineering

*"This is a production-ready PHP client for Tarantool, and v0.11.0 is a breaking release — plan the upgrade deliberately:

• PHP 8.2+ required. PHP 7.x and 8.0–8.1 are no longer supported. Services on older runtimes must stay on v0.10.1 until upgraded.
• rybakit/msgpack >= 0.11.2 required. Audit composer.lock for transitive pins before bumping.
• Native parameter and property types are now declared and enforced at runtime across the client and schema APIs. Expect failures at call sites that previously relied on loose coercion (e.g., string IDs passed to int-typed parameters) — grep and fix before rollout.
• Zero extensions (pure PHP, no msgpack PECL dependency by default).
• Middleware support for auth, retries, and logging (e.g., integrate with Laravel’s illuminate/log).
• SQL + binary protocol for flexibility (use SQL for simple queries, binary for high-performance CRUD).

Tooling/quality: PHPUnit 10, PHP-CS-Fixer 3, Psalm 5/6, CI across PHP 8.2–8.5 with combined coverage — good signal that static analysis and type safety are being taken seriously.

Tradeoffs:

• No ORM: You’ll write raw Lua-like queries (e.g., space->select(Criteria::key([1]))), but this gives predictable performance.
• Tarantool-specific: Not a drop-in for PostgreSQL/MySQL.
• Upgrade friction: The typed-API enforcement is the main migration cost, not the version bump itself.

Next steps:

1. Confirm target service is on PHP 8.2+; if not, scope the runtime upgrade first.
2. Run composer why-not rybakit/msgpack 0.11.2 and resolve conflicts.
3. Benchmark against current DB (e.g., ab or custom PHP scripts).
4. Pilot with [Y] microservice (e.g., user sessions or inventory) on v0.11.0.
5. Add to our internal PHP library for consistency, pinning ^0.11."*

Architects

*"Key technical highlights:

• Unix sockets support: Ideal for containerized or local Tarantool instances (avoids TCP overhead).
• User-defined types: Handles decimals/UUIDs natively (critical for financial or IoT data).
• Middleware pipeline: Extend with custom logic (e.g., circuit breakers, request tracing).
• Typed API surface (v0.11.0): Native parameter and property types across client and schema mean contracts are self-documenting and enforced at runtime — better static analysis (Psalm 5/6), fewer silent coercions, and a cleaner integration boundary with our own typed domain code.
• Support matrix (v0.11.0): PHP 8.2–8.5 in CI against current Tarantool releases; PHPUnit 10 test tooling. Our platform baseline should track this.

Integration notes:

• Pair with Tarantool’s Lua modules for complex logic (e.g., offload aggregations to the DB).
• Use Tarantool’s replication for high availability (but design for eventual consistency).
• Treat the v0.11.0 bump as a minor semver with real breakage: ^0.10 → ^0.11 is not a safe wildcard in a monorepo; pin explicitly and roll out service by service.

Example use case:

// Replace a slow PostgreSQL query with Tarantool’s in-memory speed
$space = $client->getSpace('user_sessions');
$session = $space->select(Criteria::key([$userId]))->first();
```"*