yaroslavche/tdlib-bundle
Symfony bundle for integrating TDLib into PHP applications, with service configuration and a convenient wrapper for building Telegram clients. It helps wire TDLib dependencies and use Telegram’s API from Symfony services.
Architecture fit. yaroslavche/tdlib-bundle is a thin Symfony DI wrapper around the TDLib PHP binding (the tdlib/td native library, consumed via the php-tdlib extension or FFI). It does not implement Telegram itself; it exposes a service, configuration, and (at most) an auth bootstrap around a stateful, callback-driven C++ client library. Architectural fit is therefore narrow and conditional: it is appropriate only if you need full MTProto client semantics — user accounts, channels, large file transfers, secret chats, or multi-account management — inside an existing Symfony application. If the requirement is a bot, the official Telegram Bot API behind a maintained SDK is materially simpler and should be the default. The bundle also assumes a long-running process; TDLib's update stream does not fit a request/response PHP-FPM lifecycle. That has downstream architectural consequences (worker daemon, supervisor, update queue) that the bundle does not solve for you.
Integration feasibility. Composer-level integration is trivial. The real cost is native: you must ship libtdjson at a pinned version, expose it via a PHP extension (preferred) or FFI (fragile, ffi.enable and ABI drift risks), and provision persistent writable storage for TDLib's local database and auth state. None of that is abstracted by the package. Feasibility is high on a Linux container you control, low on shared hosting or restrictive PaaS.
Technical risk. This is the dominant concern. At 11 stars and 0 dependents, the package is effectively a personal/unmaintained convenience wrapper. Expect: no guaranteed Symfony 6.4/7 compatibility, uncertain PHP 8.2+ support, no published support window against TDLib protocol changes, and a single maintainer. The risk profile is "you will fork and maintain this," not "you will consume this." The underlying php-tdlib binding carries its own maturity and ABI-stability questions that this bundle cannot mitigate.
Key questions.
libtdjson and a PHP extension in the image?Stack fit. Good on paper for a Symfony monolith adding Telegram user-level automation — one bundle registration, one service, config under a single key. Poor fit for serverless, FaaS, or horizontally scaled request/response services, because TDLib state is per-account and process-bound.
Migration path. Do not adopt this as a greenfield dependency without a fallback decision. Recommended sequencing: (1) prototype the underlying php-tdlib binding directly in a scratch container to validate native packaging, auth flow, and update throughput — establish whether the binding itself is viable before layering the bundle; (2) if viable, vendor or fork the bundle rather than depend on Packagist, so you control Symfony/PHP constraints; (3) treat the bundle as a configuration convenience only and own the client lifecycle, auth-state persistence, and update dispatch in application code.
Compatibility. Assume the bundle targets Symfony 4/5-era APIs and PHP 7.4/8.0. Verify service definitions against the current Symfony container (autowiring, deprecations, TaggedIterator vs !tagged). Pin TDLib to an exact version; the client-server wire format is not guaranteed stable across minor releases, and a silent TDLib bump can break authorization or deserialization.
Sequencing.
libtdjson and the PHP extension; document the FFI fallback and its limits.Maintenance. High and recurring. You inherit: the bundle (likely forked), the PHP binding, the TDLib native library, and the PHP extension build. Each has an independent release cadence; the bundle sits at the bottom of that dependency chain with no maintainer commitment. Budget realistic engineering time for an annual fork-and-rebase cycle, not a one-off integration.
Support. Effectively nonexistent. Tiny community, no vendor, minimal issue history. Internal documentation and a named owner are mandatory, not optional. Expect to read TDLib's C++ documentation and the Telegram MTProto constraints rather than package docs.
Scaling. Scales per account, not per request. Each authenticated account needs its own TDLib client, its own local database, and its own worker — memory and disk grow linearly with accounts. Telegram-side rate limits and ban risk (particularly for automation-adjacent behavior) impose a practical ceiling that infrastructure cannot buy past. Plan capacity in "accounts per node," and design account assignment to be sticky.
Failure modes. Native segfaults kill the PHP process, so isolation per account matters. FFI memory leaks degrade long-running workers slowly and invisibly. Local database corruption or loss of auth state forces re-authorization — a human-in-the-loop event at scale. Update backlogs grow silently when the worker stalls, producing stale state rather than errors. Telegram-side rate limiting and account restriction appear as protocol errors that must be classified and surfaced, not swallowed.
Ramp-up. Steep relative to the Bot API — the async/callback model, authorization state machine, and update semantics are genuinely different mental models. A mid-level Symfony engineer should be given a dedicated spike before committing to estimates. Given the low score and zero dependents, the honest recommendation is: adopt only behind a hard requirement for MTProto user-account features, with an explicit fork-and-own decision recorded before any production work begins.
How can I help you explore Laravel packages today?