во

я поясню мысль совы

во фронте у тебя во время выполнения какой-то реакции на действие юзера

например фетч данных

у тебя может еще что-то прилететь

на беке у тебя реквест единажды прилетает

ты конечно можешь его обработать как угодно с параллелизмом, асинком и прочим

на бэке же тоже самое

один реквест не завершился

уже другой прилетает

а у тебя тред другой

нет не другой

тред один

нода же

ну процесс другой

какая разница )

другая корутина фактически

процесс тоже один

запущенных async функций куча

ну им то похуй на то что в фоне работает?

нет

давай пример

Попахивает бессмысленным холиваром.

потому что они иногда работают с теми же данными, что и соседние корутины

роу-левел-лок

?

если это критично

на бэке же тоже самое

Представь у тебя есть let a = {} Тебе прилетел один запрос который его меняет после получения данных И пока первый ждет данные, прилетает второй который сразу же его меняет. Прилетает ответ от запроса на первый, у него два варианта: Опираться на старые данные, но тогда он перетрет новые данные Или же опираться на новые данные, но тогда придется заново делать запрос так как предыдущие данные не актуальны

давай пример

Один клиент добавляет запись, другой читает все записи. Эти действия могут происходить одновременно, а могут и не происходить.

транзакции

на фронте это руками решать приходится

транзакции

именно

на фронте это руками решать приходится

на фронте это просто булевские переменные к примеру

на фронте это просто булевские переменные к примеру

Сообщение выше прочти

А чат по скале есть?

есть

Нашел

Пасиба

Представь у тебя есть let a = {} Тебе прилетел один запрос который его меняет после получения данных И пока первый ждет данные, прилетает второй который сразу же его меняет. Прилетает ответ от запроса на первый, у него два варианта: Опираться на старые данные, но тогда он перетрет новые данные Или же опираться на новые данные, но тогда придется заново делать запрос так как предыдущие данные не актуальны

А в чём вопрос собственно? Обычно возвращают те данные которые из базы получены. Если между получением из базы и отправкой ответа произошли изменения, то возвращаются старые данные.

А в чём вопрос собственно? Обычно возвращают те данные которые из базы получены. Если между получением из базы и отправкой ответа произошли изменения, то возвращаются старые данные.

Нет базы данных

Есть объект

Не зацикливайся

Есть стейт, который отличается от базы тем, что полностью висит в памяти, доступен весь сразу, и две корутины обращающиеся к одному стейту не могут получить неконсистентное состояние.

Есть стейт, который отличается от базы тем, что полностью висит в памяти, доступен весь сразу, и две корутины обращающиеся к одному стейту не могут получить неконсистентное состояние.

Какие корутины

Ты о чем вообще

Я тебе дал пример

Ты ушел вообще в дебри

Реши ситуацию которую я описал

На бэке две корутины (или два потока к примеру) могут получить одну и ту же запись из базы данных в немного разное время и фактически получить разные данные.

Нет базы данных

Че ты гонишь

Объект

Обычный жс объект

На бэке две корутины (или два потока к примеру) могут получить одну и ту же запись из базы данных в немного разное время и фактически получить разные данные.

и что? )

тебе консистентность в какой момент нужна?

Представь у тебя есть let a = {} Тебе прилетел один запрос который его меняет после получения данных И пока первый ждет данные, прилетает второй который сразу же его меняет. Прилетает ответ от запроса на первый, у него два варианта: Опираться на старые данные, но тогда он перетрет новые данные Или же опираться на новые данные, но тогда придется заново делать запрос так как предыдущие данные не актуальны

Только это

ERROR: S client not available

И два хэндлера на экспрессе

Не выдумывай лишнего

Реши задачу

Или что без корутин и базы никак?

Именно поэтому ридакс, фп и иммутабельность

Что значит "решить задачу"? Где в этой задачи вопрос? Где знак вопроса? Если я правильно понимаю, то я бы посылал самые свежие данные из объекта a

Что значит "решить задачу"? Где в этой задачи вопрос? Где знак вопроса? Если я правильно понимаю, то я бы посылал самые свежие данные из объекта a

Актуальность и правильная обработка данных.

Что значит "решить задачу"? Где в этой задачи вопрос? Где знак вопроса? Если я правильно понимаю, то я бы посылал самые свежие данные из объекта a

Отправил запрос с данными. Ждешь. Объект обновился. Данные которые ты отправил стали старыми. Пришел ответ. Что делать?

Отправил запрос с данными. Ждешь. Объект обновился. Данные которые ты отправил стали старыми. Пришел ответ. Что делать?

Ипользовать полученный ответ.

Можно отправить ещё один запрос на получение самых свежих данных, но опять же нет гарантий, что объект опять не изменится в этот момент. И мутабельность/иммутабельность тут не поможет.

Ипользовать полученный ответ.

И перетереть данные

last write wins

вполне рабочая стратегия для таких случаев

Можно отправить ещё один запрос на получение самых свежих данных, но опять же нет гарантий, что объект опять не изменится в этот момент. И мутабельность/иммутабельность тут не поможет.

Изучи фп. А вообще @zerobias умеет отправлять сообщения в прошлое и будущее жизни приложения. И это как один из вариантов решения. А из существенно больше

вполне рабочая стратегия для таких случаев

Так себе стратегия когда юзер делает много действий

Терять данные нельзя

Отправил запрос с данными. Ждешь. Объект обновился. Данные которые ты отправил стали старыми. Пришел ответ. Что делать?

Обрубай запрос и шли новый.

Ааа, так вы хотите что-то наподобие CRDT

ну это знаете ли довольно интересная задача, явно выходит за рамки обычного фронтенда/бэкенда

ну это знаете ли довольно интересная задача, явно выходит за рамки обычного фронтенда/бэкенда

приходится решать эти задачи постоянно

на фронте

вот каждый раз когда делаешь запрос к бэку

кто-то даже подсчитывает количество запросов к определенной ручке

Самое простое решение: last write wins

кто-то даже подсчитывает количество запросов к определенной ручке

Яндекс....

И в большинстве случаев самое правильное

Самое простое решение: last write wins

ну удачи)

а откуда святая уверенность что фп прям жизненно-важен ? чот дичь прям совсем.