По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:
Отладка этого добра.
Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.
А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?
Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.
Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.
Понимание кода.
Возможно для команды из 1 человека проще скинуть все на контекст, оставив себе лишь написание самой логики, но на деле поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята.
Тестирование.
Здесь говорить даже ничего не надо. Думаю всем понятно, что глобальные состояния без обоснованных на то причин (это не обоснованная) если и не запрещены, то являются признаком дурного тона....именно по причине сложности тестирования.
Очереди+консольные команды.
Это вообще пиздец, я думаю и так понятно, что все эти глобальные скоупы отметаются.
Запросы к общим схемам.
Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.
Что касается ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.
Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.
И не поспоришь ведь даже...в контексте "детерминированного контекста"
По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:
Отладка этого добра.
Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.
А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?
Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.
Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.
Понимание кода.
Возможно для команды из 1 человека проще скинуть все на контекст, оставив себе лишь написание самой логики, но на деле поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята.
Тестирование.
Здесь говорить даже ничего не надо. Думаю всем понятно, что глобальные состояния без обоснованных на то причин (это не обоснованная) если и не запрещены, то являются признаком дурного тона....именно по причине сложности тестирования.
Очереди+консольные команды.
Это вообще пиздец, я думаю и так понятно, что все эти глобальные скоупы отметаются.
Запросы к общим схемам.
Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.
Что касается
ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Вариант конечно живой, но есть и альтернатива.
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.