YV
мы просто делаем модули для проекта там работа и с бд и с очередями и тд))
Та тонкая грань, когда надо перед реализация несколько раз ответить на вопрос - «мокать или не мокать» :)
Size: a a a
2020 September 26
y
Та тонкая грань, когда надо перед реализация несколько раз ответить на вопрос - «мокать или не мокать» :)
=]
ПГ
=]
Немного не теме, но если пакет для laravel он разве не должен включать laravel в required? Т. Е. И миграции будут на юзера
YV
Подскажите пожалуйста, есть сайт монолит, хотим разбить его на микросервисы, бекенд и фронт, отдельно бд и сервер распределение нагрузки. Если у нас онлайн примерно 5-6к пользователей, нужно ли сейчас беспокоится и выносить сокеты так же на отдельный сервер ? Если да на что обратить внимание при выборе сервера ?
Вы в одном вопросе смешали два разных (хоть и местами пересекающихся) вопроса:
1) масштабирование проекта
2) распил монолита на (микро)сервисы.
Вам уже достаточно подробно ответили на разницу, если не понятно, я могу попробовать ещё сверху своими словами.
По существу - если вы разделите эти задачи и сформулируете вопросы к каждой задаче независимо, то получите более конструктивную и предметную помощь :)
1) масштабирование проекта
2) распил монолита на (микро)сервисы.
Вам уже достаточно подробно ответили на разницу, если не понятно, я могу попробовать ещё сверху своими словами.
По существу - если вы разделите эти задачи и сформулируете вопросы к каждой задаче независимо, то получите более конструктивную и предметную помощь :)
y
Немного не теме, но если пакет для laravel он разве не должен включать laravel в required? Т. Е. И миграции будут на юзера
не у всех юзер модель по умолчанию и модуль не должен от этого зависить)
YV
Немного не теме, но если пакет для laravel он разве не должен включать laravel в required? Т. Е. И миграции будут на юзера
Если у вас жесткая зависимость именно на Фреймворк laravel, то надо. (Ответ с подвохом небольшим. Например, вы же помните, что есть ещё lumen).
Я бы тащил в зависимость отдельные нужные пакеты. Но тут очень многое зависит от архитектуры вашего пакета. Иногда пакеты под ларавел можно вообще сделать практически агностик.
Я бы тащил в зависимость отдельные нужные пакеты. Но тут очень многое зависит от архитектуры вашего пакета. Иногда пакеты под ларавел можно вообще сделать практически агностик.
y
Та тонкая грань, когда надо перед реализация несколько раз ответить на вопрос - «мокать или не мокать» :)
дело в том что в пакете есть конфиг и там так сказать главная модель User прописана) разраб меняет сам если захочет и все над этим подвязано) типа выборок и тд) создается класс из модели которая в конфиге)) не у всех App\User по умолчанию) да и привязываться к этому не хочется) иначе всему настанет конец)
y
грубо говоря жестко зависимым не хочется быть к App\User)
y
а если у него пару моделей User Admin Moder и взависимости от урла ему надо менять модель) через конф и выбирать из нужной таблицы) и вот тут уже проблема будет огромная если привязываться только к App\User
YV
Так а в чем проблема, если класс в конфиге задается?
y
Так а в чем проблема, если класс в конфиге задается?
да) но у пакета нет такого класса) придется создать по умолчанию а миграцию только в тестах)
y
да) но у пакета нет такого класса) придется создать по умолчанию а миграцию только в тестах)
и фабрику)
YV
а если у него пару моделей User Admin Moder и взависимости от урла ему надо менять модель) через конф и выбирать из нужной таблицы) и вот тут уже проблема будет огромная если привязываться только к App\User
Ну тут же от архитектуры надо смотреть. Во-первых, не факт, что admin - это отдельная модель (если абстрактно смотреть). Во-вторых, часто можно в рантаме менять (я не говорю сейчас про хорошо / плохо). Тут целиком надо смотреть, так как «кусочно» смотреть - много вопросов
y
Ну тут же от архитектуры надо смотреть. Во-первых, не факт, что admin - это отдельная модель (если абстрактно смотреть). Во-вторых, часто можно в рантаме менять (я не говорю сейчас про хорошо / плохо). Тут целиком надо смотреть, так как «кусочно» смотреть - много вопросов
вот и я выше скзаал про реал тайм смены модели) и выборка уу нужной модели)
y
спасибо короче ))😁😁
YV
Ооокей :)
ПГ
да) но у пакета нет такого класса) придется создать по умолчанию а миграцию только в тестах)
Мне кажется вы пытаетесь усидеть на двух стульях: одновременно завязаться на User и одновременно от него отвязаться )
А
дело в том что в пакете есть конфиг и там так сказать главная модель User прописана) разраб меняет сам если захочет и все над этим подвязано) типа выборок и тд) создается класс из модели которая в конфиге)) не у всех App\User по умолчанию) да и привязываться к этому не хочется) иначе всему настанет конец)
Кто мешает тебе в тестах мокать конфиг и подставлять нужную модель?
y
Кто мешает тебе в тестах мокать конфиг и подставлять нужную модель?
так вот я так делать и буду) только откуда я в пакете возьму модель юзера? для этого ее нужно создать) и миграцию тоже)
y
Мне кажется вы пытаетесь усидеть на двух стульях: одновременно завязаться на User и одновременно от него отвязаться )
завязаться только на
\Illuminate\Foundation\Auth\User