n
И все эти велосипеды автоматом пропадут
Size: a a a
2020 December 02
OW
А почему не реализовать конкретные остатки и конкретное резервирование?
Так и сделано, есть поступления
Есть продажи
И так всё хранится в одном месте, а постоянно обновлять остаток мне кажется ненадёжным решением
Есть продажи
И так всё хранится в одном месте, а постоянно обновлять остаток мне кажется ненадёжным решением
n
Так и сделано, есть поступления
Есть продажи
И так всё хранится в одном месте, а постоянно обновлять остаток мне кажется ненадёжным решением
Есть продажи
И так всё хранится в одном месте, а постоянно обновлять остаток мне кажется ненадёжным решением
Ключевое слово кажется)
OW
Каждый дрочит как хочет
n
Обновлять не постоянно, а при конкретных операциях
n
Каждый дрочит как хочет
И это пугает)
OW
И это пугает)
Я так сохраняю больше целостности, мне не нужно думать, что где-то вот товар купили, а в остаток не записали
n
Я так сохраняю больше целостности, мне не нужно думать, что где-то вот товар купили, а в остаток не записали
Не думать плохой вариант 🙈
OW
Не думать плохой вариант 🙈
Думать, что прав только ты, тоже не лучшая затея
E
привет
где и как хранить токен с кук реквеста на сервере для дальшейших запросов с заголовоком auth?
т.е. есть бэк прослойка, куда летят запросы юзера. Далее этот бэк делает запросы к другому апи, на котором проверяется наличие header auth и т.д.
Спасибо
где и как хранить токен с кук реквеста на сервере для дальшейших запросов с заголовоком auth?
т.е. есть бэк прослойка, куда летят запросы юзера. Далее этот бэк делает запросы к другому апи, на котором проверяется наличие header auth и т.д.
Спасибо
OW
Ты не привел доводов, что твой вариант чем-то лучше, он просто проще, а я лучше заморочусь и получу куда больше выгоды
d.
привет
где и как хранить токен с кук реквеста на сервере для дальшейших запросов с заголовоком auth?
т.е. есть бэк прослойка, куда летят запросы юзера. Далее этот бэк делает запросы к другому апи, на котором проверяется наличие header auth и т.д.
Спасибо
где и как хранить токен с кук реквеста на сервере для дальшейших запросов с заголовоком auth?
т.е. есть бэк прослойка, куда летят запросы юзера. Далее этот бэк делает запросы к другому апи, на котором проверяется наличие header auth и т.д.
Спасибо
никак
n
Думать, что прав только ты, тоже не лучшая затея
Я не говорил что то что ты пытаешься сделать не будет работать. Я сказал о том, как с этим всем проще работать
d.
привет
где и как хранить токен с кук реквеста на сервере для дальшейших запросов с заголовоком auth?
т.е. есть бэк прослойка, куда летят запросы юзера. Далее этот бэк делает запросы к другому апи, на котором проверяется наличие header auth и т.д.
Спасибо
где и как хранить токен с кук реквеста на сервере для дальшейших запросов с заголовоком auth?
т.е. есть бэк прослойка, куда летят запросы юзера. Далее этот бэк делает запросы к другому апи, на котором проверяется наличие header auth и т.д.
Спасибо
auth это фронтовая тема, внутри сервисы гоняй со своим залогвоком user ID
OW
Я не говорил что то что ты пытаешься сделать не будет работать. Я сказал о том, как с этим всем проще работать
Я понимаю, что так проще, но я знаю и какие минусы от такого решения, поэтому остановился на своём выборе
n
Я понимаю, что так проще, но я знаю и какие минусы от такого решения, поэтому остановился на своём выборе
Когда плюсы называешь минусами.. 🙈😂
OW
Когда плюсы называешь минусами.. 🙈😂
😘
n
Простое лучше сложного
Сложное лучше запутанного
Сложное лучше запутанного
E
auth это фронтовая тема, внутри сервисы гоняй со своим залогвоком user ID
Понял, спасибо. А можете пжлст чуть подробней про "внутри сервисы гоняй со своим залогвоком user ID"
d.
Понял, спасибо. А можете пжлст чуть подробней про "внутри сервисы гоняй со своим залогвоком user ID"
auth это для фронтового апи, который удостоверяется что юзер это юзер. внутренние сервисы закрытые им должно быть посрать как юзер проверялся, им дают юзер ид, может юзеонейм незнаю что надо и работают с этим контекстом