AN
Size: a a a
2021 February 26
GS
А лучше не .sh, а например .js
N
А лучше не .sh, а например .js
точно
N
просто там будет наборчик child_process.exec() ?
GS
Нефиг просто так (из лени?) добавлять ОС зависимость в таких простых местах
A
зучит так, будто бы админка это отдельный слой
бестпрактис вынести админку в отдельный сервер, отдельный сайт и бд ему предоставить чисто на чтение и желательно на слейве какомто))
AN
А лучше не .sh, а например .js
А какой API конкретно нужно юзать для этого? Можете дать наводку?
GS
А какой API конкретно нужно юзать для этого? Можете дать наводку?
Выше Никита написал,
Либо использовать пакеты для запуска задач.
Если у вас репозиторий с множеством проектов - npm пакетов, можно ещё в сторону воркспейсов посмотреть
require('child_process').exec.Либо использовать пакеты для запуска задач.
Если у вас репозиторий с множеством проектов - npm пакетов, можно ещё в сторону воркспейсов посмотреть
АП
Adv0cat
бестпрактис вынести админку в отдельный сервер, отдельный сайт и бд ему предоставить чисто на чтение и желательно на слейве какомто))
и там всё сделать без слоёв? и репозиторий, и сервисы - всё в одном файле?
A
зря быкуете))
да, потому что есть акция которая действует для магазина если он продал за период на сумму больше Х
да, потому что есть акция которая действует для магазина если он продал за период на сумму больше Х
Хто быкует?)) Да бросьте вы)) Делайте что хотите))) Рамок нет)))
N
ну чтобы посторонние запрос не выполнили
кто посторонний? так запрос я буду в рамках логики приложения выполнять
выше описал юз кейс
выше описал юз кейс
AC
Adv0cat
бестпрактис вынести админку в отдельный сервер, отдельный сайт и бд ему предоставить чисто на чтение и желательно на слейве какомто))
можно просто не мешать api роуты юзера и админа, убирать crud
A
можно просто не мешать api роуты юзера и админа, убирать crud
Та можно сделать что угодно, было бы желание 😅
AC
зря быкуете))
да, потому что есть акция которая действует для магазина если он продал за период на сумму больше Х
да, потому что есть акция которая действует для магазина если он продал за период на сумму больше Х
хех тогда проще сделать отдельный сервис для накопления заказов в период акции: + к юзабилити и меньше запросов к бд
N
хех тогда проще сделать отдельный сервис для накопления заказов в период акции: + к юзабилити и меньше запросов к бд
вопрос же в 1 запросе который считает сумму 1 поля, а вы предлагаете целый сервис сделать, чтобы в коде который накапливает заказы еще больше ошибок сделать)
ЮК
а кто-нибудь еще помнит сам вопрос?)
N
Где писать запросы к БД которые не вписываются в функционал репозитория (найти/создать/изменить/удалить запись)? Т.е. агрегации всякие или которые выбирают 1 поле какое то
N
(вариант что типа у нас админка отдельная не учитывается)
ЮК
я бы пересмотрел назначение репозитория...