- What does overblog/thrift-bundle actually do?
- It is a thin Symfony bundle wrapper around the Apache Thrift PHP runtime. It generates PHP client and processor classes from .thrift IDL files, registers generated clients and handlers as dependency-injection services, and wires transport and protocol stacks such as TSocket, TBufferedTransport or TFramedTransport, and TBinaryProtocol or TCompactProtocol. It also provides an optional server-runner command. It is not a standalone RPC framework; everything depends on the Apache Thrift compiler and runtime being installed and version-matched.
- Can I use overblog/thrift-bundle in a Laravel application?
- No, not directly. It is built as a Symfony bundle and relies on Symfony bundle registration, dependency-injection conventions, and container wiring rather than Laravel service providers. If you need Thrift in Laravel, use apache/thrift directly behind your own service factory and anti-corruption layer, or fork the bundle and adapt it. For greenfield Laravel service communication, gRPC, symfony/messenger-style queues, or REST/JSON-RPC are usually better fits.
- How do I install overblog/thrift-bundle and generate PHP classes from Thrift IDL?
- Install it with Composer using composer require overblog/thrift-bundle, then enable the bundle in your Symfony kernel or bundles.php. You configure the IDL paths, generated namespace, and service definitions, and the bundle triggers generation of PHP client and processor classes. The thrift compiler binary must be available at build time, so the real setup cost is toolchain pinning rather than the Composer install itself.
- Do I need the Thrift compiler installed to use this bundle?
- Yes. The bundle generates PHP client and processor classes from .thrift IDL, which requires the Apache Thrift compiler binary. You also need the apache/thrift runtime library at runtime. Pin the compiler and runtime versions identically in development, CI, and production images, and match them to the Thrift version used by the peer service because wire compatibility across minor versions is not guaranteed for every transport and protocol combination.
- Which Symfony and PHP versions does overblog/thrift-bundle support?
- The last release was in May 2019, so it targets the Symfony 3 and 4 era and older PHP versions. Symfony 5, 6, and 7 changed bundle and DI conventions significantly, so expect to patch or fork the wiring. PHP 8.x compatibility of the generated stubs and the bundled Thrift dependency must be tested rather than assumed.
- Does overblog/thrift-bundle support both Thrift clients and Thrift servers?
- Yes. It registers generated clients for calling a Thrift server and handler or processor classes for exposing Thrift services, plus an optional server-runner command. In practice, the client side fits the PHP-FPM request/response model only for short calls. Serving long-lived Thrift connections, streaming, or high-fanout aggregation from PHP is not a good fit.
- Is overblog/thrift-bundle still maintained or abandoned?
- It is effectively unmaintained. The last release was 2019-05-09, it has roughly 44 stars and zero dependents, which points to a single-maintainer artifact with no active CVE response path. Treat it as a starting point to vendor or fork, not as a dependency you can rely on for long-term Symfony and PHP upgrades. Decide in advance who owns the fork when an upgrade breaks it.
- What are the production risks of using Thrift in PHP-FPM with this bundle?
- The bundle is a synchronous RPC wrapper and does not provide pooling, timeout defaults, retries, or circuit-breaking behavior. That is acceptable for short client-side calls in a request/response PHP-FPM model, but it is a poor fit for long-lived connections, streaming, or high-fanout aggregation. Add your own timeouts, failure handling, and an anti-corruption layer around the generated clients before using it in production.
- What are alternatives to overblog/thrift-bundle for Thrift in PHP?
- The preferred alternative is to skip the bundle and use apache/thrift directly behind a small Symfony or Laravel service factory plus your own interfaces. You replace unmaintained glue code with roughly the same amount of code you control and remove the fork liability. Another option is a sidecar or bridge: run the Thrift client in Go or Java, or put a Thrift-to-HTTP or Thrift-to-gRPC bridge in front, and let PHP speak HTTP or gRPC. For greenfield communication, gRPC/protobuf, symfony/messenger, or REST/JSON-RPC are stronger choices.
- Should I commit generated Thrift stubs or generate them in CI?
- Both approaches work, but they trade different risks. Committing generated stubs avoids build coupling but creates drift risk when the IDL or compiler version changes. Generating in CI keeps stubs aligned with the pinned thrift compiler but makes every build depend on the toolchain. Whichever you choose, add integration tests against the real peer service and unit-test your handlers so protocol and version mismatches are caught early.