Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Thrift Bundle

Thrift Bundle Laravel Package

overblog/thrift-bundle

Symfony bundle that integrates Apache Thrift, letting you expose and consume Thrift services with configurable protocols, transports, and serialization. Register services, clients, and servers as container services with flexible per-service configuration.

View on GitHub
Deep Wiki
Context7

OverBlog ThriftBundle integrates Apache Thrift into Symfony applications, letting you expose and consume Thrift services using familiar Symfony conventions. It wires Thrift service definitions into the container, generates PHP client and server classes from .thrift files, and handles the transport and protocol configuration for you. This makes it practical to build cross-language RPC services without hand-writing glue code.

  • Service generation from .thrift IDL files via a console command
  • Container integration for Thrift clients and servers as Symfony services
  • Configurable transports and protocols (socket, TBinaryProtocol, etc.)
  • Support for multiple Thrift services in one application
  • Bundled Symfony console commands to compile and manage definitions
Frequently asked questions about Thrift Bundle
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect
youbar/easy-crud
c-point-labs/laravel-hostyourai
dbravoan/dbcms-admin-theme-dbcms
dbravoan/dbcms-theme-db-cyber
dbravoan/dbcms-blocks-basic
dbravoan/dbcms-module-content-audit
dbravoan/dbcms-module-ai-assistant
paygate-to/paygate-php
padosoft/askmydocs-connector-base
defstudio/supercharged-carbon
bernskioldmedia/laravel-matomo