То, что вы хотите заколхозить, называется кэширование и для него есть куча готовых нормальных решений.
Извините, я не верю, что у вас на проекте 50 000 одновременных пользователей и при этом нет ни одного компетентого человека, который понимает, что хранить данные в JSON-файлах не нужно. Больше похоже на влажные фантазии.
У вас уже прямо сейчас есть конкретные проблемы с нагрузкой на БД, которые нельзя решить оптимизацией алгоритмов и запросов? Полагаю, что нет, и вы занимаетесь преждевременной оптимизацией придуманных будущих проблем. Попытка предсказать проблемы и их заранее устранить - это не всегда плохо, но в данном случае и проблема надуманная, и решение этой надуманной проблемы предложено плохое.
P.S. У меня на одном проекте есть таблица с ~6 000 000 000 строк, занимающая почти полтерабайта. Вот там пришлось ещё слегка обмазать Редисом, чтобы не заставлять пользователя ждать окончания вставки новых значений.
Никто не отвечает. У меня тоже времени разбираться нет, но помогу, чем смогу. Кажется, что всё должно нормально работать и так, но вот у нас на проекте с точно такой же задачей зачем-то сделано отдельное middleware, которое переключает guard, а не используется auth:guard. Почему так сделано сейчас уже не вспомню, много лет прошло, но, видимо, была всё же какая-то причина.
Параллельно - это для одних и тех же роутов чтобы работала и та и другая (т.е. желаете странного) или для одного набора роутов один способ валидации, а для другого другой (т.е. нормальный сценарий).
У вас в коде лапша. Объекты вы называете массивами, код не отформатирован нормально, полная структура объекта не приведена. Поэтому приходится догадываться, чего вы реально хотели.
А в ответе у меня что за разноцветные буковки, по вашему, написаны?
Но даже без них - вы реально не в состоянии понять/нагуглить из ответа в чём смысл проблемы и исправить самостоятельно? Это важный навык для программиста.
Извините, я не верю, что у вас на проекте 50 000 одновременных пользователей и при этом нет ни одного компетентого человека, который понимает, что хранить данные в JSON-файлах не нужно. Больше похоже на влажные фантазии.
У вас уже прямо сейчас есть конкретные проблемы с нагрузкой на БД, которые нельзя решить оптимизацией алгоритмов и запросов? Полагаю, что нет, и вы занимаетесь преждевременной оптимизацией придуманных будущих проблем. Попытка предсказать проблемы и их заранее устранить - это не всегда плохо, но в данном случае и проблема надуманная, и решение этой надуманной проблемы предложено плохое.
P.S. У меня на одном проекте есть таблица с ~6 000 000 000 строк, занимающая почти полтерабайта. Вот там пришлось ещё слегка обмазать Редисом, чтобы не заставлять пользователя ждать окончания вставки новых значений.