Дружим gRPC с долгоживущим проектом, PHP и фронтендом

[m8rge]

Как тестировать это чудо?

[vladqa]

Не очень понятно, что именно подразумевается под «этим чудом» и о каком тестировании идет речь. Если речь идет о том, как тестировать API, то ответ простой: так же, как любое другое API. Клиент генерируется автоматически. Остается лишь написать ассерты.

[Lachezis]

Здорово!

Мы написали свой PHP процесс менеджер примерно для таких же целей — https://github.com/spiral/roadrunner

Только вместо FAST-CGI работаем с несколькими демонизированными PHP процессами через пайпы и бинарный протокол (без бутлоада получается ускорить отзывчивость точки раз в 10-30).

[vladqa]

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

А насчет оптимизации производительности: у вас интересный порядок цифр 10-30 раз. Если не секрет, с чем производилось сравнение?

[Lachezis]

У нас была цель внедрить RPC точки в старый код (+queue в некоторых случаях), производительность это просто побочный эффект выноса коммуникации в сам процесс. Давно зреет идея повесить GRPC прокси сверху, но для начала хотим закончить PSR-7 сервер на этой штуке.

Фреймворки работают на ура, главное чтобы компоненты были написаны правильно и не текла память. Плюс библиотека включает failswitch для корректного завершения процесса в случае каких-либо проблем.

Сравнивали со своим же фреймворком (spiral, лежит в той же огранизации), но под nginx+php-fpm. Чем больше бутлоад проекта тем больше разница в производительности. В некоторых тестах с участием баз данных удавалось выжать разницу в 65 раз.

[vladqa]

главное чтобы компоненты были написаны правильно и не текла память

Из-за этого мы не рискнули применять такой подход. Ранее рассматривали вариант перехода на PHP-PM, который работает по схожему принципу. Но у нас довольно много сишных екстеншенов используется и стороннего кода из Composer. Сложно ручаться за все библиотеки.

И еще страшно за транзакции/сейвпоинты в БД. Если где-то в одном месте она не закрыта случайно, то, кажется, все следующие запросы будут под угрозой. Навскидку приходит только либо отдать контроль за этим приложению (ввести счетчик и надеяться, что все будут открывать транзакции через контроллируемый нами метод), либо перед обработкой запроса ходить в БД за информацией о транзакции на этом подключении.

В любом случае хорошо, что в мире PHP потихоньку происходит изменение подхода к построению приложений. Лично я надеюсь, что в будущем появится больше удобств для создания фуллстек-приложений и со стороны интерпретатора.

[SonicGD]

Где-то в ближайшее время Google выкатит свой grpc-web