Привет, текущее положение дел по шаблонам приложений

1. Самый нижний слой — SDK
https://github.com/bitrix24/b24phpsdk — плановые релизы раз в месяц по расширению функционала библиотеки.

2. Слой хранения данных — фреймворк-агностик (не зависящий) от фреймворка
https://github.com/mesilov/bitrix24-php-lib/
Тут созданы две сущности отвечающие контрактам из b24phpsdk:
Bitrix24Accounts — храним токены и вот это все связанное с их жизненным циклом
ApplicationInstallations — храним факты установок \ удаления приложения и его жизненного цикла

Т.е. это тот самый минимум, который надо для запуска:
- локального приложения
- тиражного приложения

На этой неделе закончим причесывать до первого релиза 0.x
Т.к. тут уже вариативность существенно больше, то пилим с двумя другими разработчиками, MIT вот это все.

Если прям придерживаться symfony \ laravel way, то там надо делать Symfony‑bundle и Laravel‑adapter, там есть выбор, чтобы это было в одном репе или несколькро репов.
Сейчас, если разработчик на Symfony \ laravel захочет использовать bitrix24-php-lib, то ему придется руками все что надо сконфигурировать у себя (пока нет бандла \ адаптера). Есть такие?

На текущий момент мне гораздо важнее проверить работу всех пользовательских сценариев, поэтому тут пока работы поставил на паузу, делаются только мелки вещи вроде поправить тесты, исправить очевидные косяки и т.д.

3. Шаблоны репозиториев на Symfony \ Laravel
Основная точка приложения усилий, сейчас собираю шаблон симфони, чтобы проверить сценарии которые реализует bitrix24-php-lib и то насколько безболезненно можно все в кучу собрать.
https://github.com/mesilov/bitrix24-application-symfony-template — работы тут
Как только отлажу на симфони сценарии (установка, удаление, очереди и т.д), то можно будет сделать бандл \ и адаптер для Laravel.
Такие вот дела.

Что по инфраструктуре?

Приложение работает поверх инфраструктуры, нфраструктурной единицей у нас будет докер-контейнер.
Вопрос в том, что будем выбирать в качестве аппликейшн\веб-сервера. Какие у нас варианты:

Встроенный в PHP dev-сервер
Все запускаем на встроенном в PHP дев-сервере, а production конфигурация это не наша головная боль. Крутитесь как хотите.
У всех пользователей начинает болеть голова, а как это вот все запускать и обслуживать.

nginx + phpfpm
Есть миллион рецептов, проверено годами, собрали @ запустили, для production контура каждый самостоятельно решает ряд вопросов: выпуск сертификатов, логи, телеметрия и т.д.
ru и западное комьюнити в целом понимают, что это такое и как настраивать. На уровне шаблонов приложений даем базовую конфигурацию и дальше сами конфигурируйте как хотите.
Отложенная проблема: развитие nginx начиная с 2022 года стагнирует. Приложения для Битрикс24 не упрутся в «архитектурные» ограничения nginx, но вот экосистема не предоставляет удобных решений «из коробки», настраивайте все сами, как лично вам удобно будет ©.

angie
Это форк nginx от русскоязычной части core-команды nginx, развивается более динамично, русскоязычное комьюнити. Если у вас есть «черный пояс по nginx», то это хорошая замена, которая отвечает на значительную часть требований к современному приложению. Если говорим про западное комьюнити, то выбор angie вызовет некоторые вопросики.
Ну и никуда не девается история с long-running режимом работы php, к которому старательно пытается подойти php-комьюнити.
Более детально с tech-drama можно ознакомиться глянув эти доклады:
https://www.youtube.com/watch?v=Qx9BB7w4mt4 — php и angie
https://www.youtube.com/watch?v=QeI5GMP4ukM&t=15s — деды под пиво бухтят и рассказывают закулисную часть истории

frankenphp
Если вы последний год сидели в пещере и пропустили все новости, то у PHP появился свой application-server.
https://thephp.foundation/blog/2025/05/15/frankenphp/
Из минусов: нужно выучить новый «птичьий язык» конфигурации веб-сервера caddy.
Из плюсов:
— аппликейшн-сервер развивают люди, которые знают с какой стороны PHP запрягать — Kévin Dunglas, creator of API Platform and Symfony Core Team member.
— готовые сценарии для наших любимых фреймворков (Symfony, Laravel, БУС)
— комьюнити адаптирует фреймворки\сценарии и всю обвязку под текущий стек, а под условный nginx вы должны будете портировать конфиги сами.

Поэтому, выбираем в качестве application-server frankenphp 🤔 и на нем отлаживаем «production-ready» конфигурацию приложения, заодно посмотрим, как это выглядит в реальности, а не на бодрых докладах инфлюенсеров с ютьюба, у которых все само работает.