в целом была идея красиво всё это оформить и выложить в качестве готового решения на гит, но всё руки не доходят

сейчас напишу более подробную реализацию

еси соберешься пилить, то правильно было бы обращаться не к контроллеру, а к «сервису». Контроллер обычно содержит сетевую логику внутри, а я так понял при прямых вызовах она должна игнорироваться. Чисто вопрос терминологии.

я же написал как отмасштибировать, т.е. если нужен только фронт который общается исключительно по http, то это легко делается парой движений, ну в конце концов, если такая необходимость будет, то эти пара движений, легко выносятся в .env например
в моём случае если есть у фронта коннект до MySQL то он может быть и бэком и фронтом одновременно или по отдельности
2. найдётся так же быстро как и человек знающий Ноду и/или экспресс. Сам код коннекта это 279 строк кода.

ещё раз повторяю, моё решение может одновременно выступать как фронт и как бэк. Притом может быть только бэком или только фронтом

а тем более MySQL

Минусы:
- php медленнее ноды
- больший стек технологий
- разные ЯП для бэка и фронта

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

Отказ моего Фронта наоборот не ведет к отказу системы . Падает только мой сервер. Мобильное придожение заточенное на сервис же будет работать. А вот в вашем случае нет. Понятно что можно все масшабировать, запустиить пару подов и тд