Мультитенантность без глобальных скоупов с сигаретой в зубах. Хипстер PHP

[@roxblnfk]

Не понял, чем помешали исключения и почему в PHP они подразумеваются для общения между слоями. Исключение — это просто исключение и бояться его не надо.

Представленный подход с хендлерами в Rift выглядит прикольно. Но чёт мне кажется, что проблема с мультитенантностью слишком преувеличена: переключаться между тенантами можно тупо в мидвари, создавая тенантно-ориентированную область видимости. Причём за мидлварью код будет всё тот же, как с одним клиентом.

[@mainbotan]

По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:

1. Отладка этого добра.

   Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.

   А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?

   Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.

   Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.

2. Понимание кода.

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

3. Тестирование.

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

4. Очереди+консольные команды.

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

5. Запросы к общим схемам.

   Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.

Что касается ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.

[@roxblnfk]

на мидлварь для роутов

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

А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?

Стоп. А кто код то пишет? Как может установиться неправильный контекст? Неведомых причин в подконтрольной среде не бывает.
Но допустим у нас есть фактор рукожопости от неопытной команды джунов и господь, который иногда помогает не случиться страшным вещам. Эта нить рассуждения продолжится чуть ниже.

Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано

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

То, о чём говорю я, называется областью видимости контейнера. Это не магическое глобальное состояние. Это как раз таки то самое "строго изолированное".
В этом случае нельзя будет получить тенанто-зависимый сервис/репозиторий/что-угодно, если не определён тенант.
Не надо будет вручную брать тенанта из jwt и просовывать его в обмен на репозитории тенанта. Всё, что про "вручную" — это не про изоляцию и безопасность, это про возможность накосячить или выстрелить в ногу. Лучше делать так, чтобы один раз описанные механизмы делали всё за человека, а человек думал только о бизнес-логике. В обмен на сокрытие шаблонного кода получаем: джун сможет нарукожопить только в пределах дозволенного, а господь лучше займётся чем-то более полезным.

поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята

Детерминированный контекст != магия.

глобальные состояния

Ещё раз напомню, это не про глобальные состояния. Это про изолированный контекст, который легко тестируется.

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

Нет, тут всё наоборот :)

Запросы к общим схемам.

Абсолютно без проблем. Общие схемы остаются общими и доступными из родительского контекста, если не переопределены в дочернем.

[@mainbotan]

И не поспоришь ведь даже...в контексте "детерминированного контекста"