тут речь про фронтед-микросервисы, это два сервиса работающих на одной и той же странице в 1 браузере. их можно хоть прямой передачей JS колбеков связать. ну или через postMessage если они изолированы в воркерах.
Константин Б., код в котором map вызывается целиком покажите. То что перед точкой. Да и вообще для таких вопросов лучше готовый плейграуyд делать https://www.typescriptlang.org/play с ошибкой и постить ссылку.
tvsjke, это примерно то же что и на все роуты один айпишник. только найти проще, выглядеть будет красивше, потенциальный "хакер" будет благодарен.
V-ampre, подход нормальный, защищаются от конкретных рисков, "привык мыслить" к реальным проектам мало имеет отношения, это просто паранойя. Хотите чтобы пользователь ничего не знал - удалите свой сайт, способ 100%. Все остальное требует разумного подхода.
Хотите защищаться - проанализируйте возможные векторы атаки, вероятность их осуществления и потенциальный вред. После этого думайте что и где поменять-защитить. Может у вас и нет их, проблем настоящих.
Если у вас реальный риск утечки информации о том какие роли есть в системе, и это может принести реальный вред - то переделывайте систему так чтобы в урлах этой информации не было. Но практически наверняка она будет в коде в другом виде все равно.
Если вам не принципиален HTTP и вы вольны выбирать протокол, то GraphQL решает эти вопросы на 200%.
описываете протокол в одном месте и генераторы вам генерят все остальное. Либо типы/классы для ts/c# из graphql файлов или наоборот (не уверен что есть хорошие тулзы для c# для этого случая)
+ в коде вы получаете сразу готовые провалидированные объекты, а не пачку неизвестных параметров или произвольное body.
Edward D, тут через день появляются такие вопросы с припиской "я все ответы прочитал, но ответов именно на свои вопросы не нашел. Потому что у меня <язык/город/возраст/особый работодатель/кошка рыжая/любая другая незначительная деталь>, а про это никто не писал"
Вы и не найдете ответов на "именно свой вопрос" потому что на самом деле он звучит так "у меня страх, нерешительность и неопределенность, я не знаю что делать, боюсь позвонить хотя бы по одной вакансии и хочу поддержки". С такими вопросами - это не на тостер. Тут технический ресурс.
Если бы у вас действительно была задача узнать, нужна ли вышка при устройстве на работу на те вакансии которые вам интересны - вы бы по всем этим вакансиям уже позвонили, узнали, нужна ли им там вышка, собрали инфу и статистику и знали ответ на этот вопрос.
Horus123, это больше вопрос к серверу - почему там именно такая авторизация а не какая-то другая. Это не самый безопасный и юзер-френдли способ.
Удобнее и правильнее будет либо авторизация с сессиями через куки, либо, как вы сказали, токен, у которого есть срок действия, в разных вариантах - от простого jwt до oauth авторизации.
Хранить имя-пароль где-то в браузере можно конечно но я бы не рекомендовал так делать. Только как крайний случай, когда риски не большие а выгода значительная.
Никита Корнилов, вам в любом случае надо будет что-то делать самому, просто БД предоставляет вам инструменты с помощью которых этого можно реально достичь. Такого чтобы взял БД и у вас автомагически такие конфликты решаются - нет. Не знаю насчет монго, я не копался там настолько. Можно начать отсюда: https://docs.mongodb.com/manual/core/transactions/
Но в любом случае, вам надо будет разобраться в транзакциях, их типах, атомарности операций. Не зависимо от того монго вы используете или что-то другое.
Общая схема может выглядеть, например, как-то так:: вы открываете транзакцию, читаете количество доступных товаров, создаете то что нужно создать для заказа, изменяете количество доступных товаров и делаете коммит транзакции, транзакция должна быть такой чтобы в момент коммита гарантировать что прочтенное количество доступных товаров не изменилось.
Если это выполняется, ваши данные обновляются, если коммит транзакции вызвал ошибку, значит данные за это время поменялись, и вам надо запустить процесс оформления заказа по новой - прочитать значение доступных товаров из базы и так далее.
А вот как добиться этой логики - вы уже читаете документацию по БД.
На самом деле проще как раз второй вариант ;) Очередь делается из обычного массива в JS в 15 строчек и вы забываете про проблемы одновременной записи.
Денис Юрьев, вы же понимаете что это не тот случай и тут нет команды, разных ОС, и всего остального? или нет? или понимаете, но считаете что хорошее решение хорошо всегда, везде и в любой ситуации, и если лично вам что-то проще, то и всем вокруг, в любой ситуации, в том числе и автору данного вопроса это тоже будет проще, даже если автор не то что докер развернуть как среду разработки, или nginx поднять как прокси а даже понять проходит у него запрос или нет, пока не в состоянии?
Денис Юрьев, поднимать локально докер просто чтобы запустить ноду - такая себе идея.
Учитывая что это разработка, и там по сто раз надо сервер обновлять - перезапускать.
