MY
просто как только потрогал нест, сразу даже чисто интуитивно стало понятно, что пока что за ним будущее в мире node.js
Size: a a a
2020 February 20
MY
только интересно, как там loopback 4 поживает
VA
Кайф, доделал я кэш через редис. По финалу что бы не выстрелить себе в ноги, сделал что при обновление каких либо данных, я просто буду стирать весь кэш. Да, тут будет прикол в том что первые запросы могут быть чутка медленнее, но зато я буду уверен что кэш актуален, а уже потом пусть редис отрабатывает. Думаю потом сделать еще и memCached, но это не точно.
M
Кайф, доделал я кэш через редис. По финалу что бы не выстрелить себе в ноги, сделал что при обновление каких либо данных, я просто буду стирать весь кэш. Да, тут будет прикол в том что первые запросы могут быть чутка медленнее, но зато я буду уверен что кэш актуален, а уже потом пусть редис отрабатывает. Думаю потом сделать еще и memCached, но это не точно.
Этим подходом пользовался, отрабатывало всегда норм.
*не огромные распределенные системы
*не огромные распределенные системы
VA
Этим подходом пользовался, отрабатывало всегда норм.
*не огромные распределенные системы
*не огромные распределенные системы
Мне понравилось что при учете что nest в кластере, он выдает мне под 60тыс запросов в сек, на запросах с graphql. Да, таких нагрузок в жизни этого проекта точно не будет, но если можно сделать на будущее, почему бы и нет. Буду этот модуль использовать если что потом на других проектах.
VA
В этом подходе еще нравится то что база ну будет блокировано на запись и можно пулять в нее больше запросов, в то время как за отдачу будет отдуваться редис.
VA
Хотя я бы еще чутка доработал, а именно не удалять весь кэш редиса, а только то что может быть связано с измененной сущностью. Но это чутка сложнее держать под контролем, нужно больше внимания уделять и быть внимательным что бы не профукать.
VA
Сейчас @jashka_jashka скажет что я опять что-то не так сделал :)) да ?
M
Я думал вы удаляете не весь кеш редиса, а только то, что изменилось
LK
все это можно было бы сделать куда легче если бы у тебя были 2 базы: для записи, по сути мапинг сырые данные, и только БЛ с ними работает
и база для чтения
вопрос в том как только синкать данные между БД
при записи сделать проекцию для БД где только идет чтение
а БД для чтения можно уже под UI сделать что бы проще было данные выбирать
и база для чтения
вопрос в том как только синкать данные между БД
при записи сделать проекцию для БД где только идет чтение
а БД для чтения можно уже под UI сделать что бы проще было данные выбирать
VA
Я думал вы удаляете не весь кеш редиса, а только то, что изменилось
Пока что весь, просто нужно скачало сделать всю структура и потом уже буду смотреть какие есть связи что бы удалять только то что нужно.
LK
и не нужно крутить БЛ так что бы и тебе было удобно на бекенде работать с базой и для клиента городить для удобства
IL
вопрос.. как в NestJS устанавливать куки?
Я смотрю в доках вообще ничего об этом нет
единственное что приходит на ум - свой декоратор, который мне пробросит из res.cookie объект, где я уже вручную засетаплю куку.
Но может есть более элегантное решение? (разве что сделать то же самое, но в интерцепторе)
Я смотрю в доках вообще ничего об этом нет
единственное что приходит на ум - свой декоратор, который мне пробросит из res.cookie объект, где я уже вручную засетаплю куку.
Но может есть более элегантное решение? (разве что сделать то же самое, но в интерцепторе)
VA
все это можно было бы сделать куда легче если бы у тебя были 2 базы: для записи, по сути мапинг сырые данные, и только БЛ с ними работает
и база для чтения
вопрос в том как только синкать данные между БД
при записи сделать проекцию для БД где только идет чтение
а БД для чтения можно уже под UI сделать что бы проще было данные выбирать
и база для чтения
вопрос в том как только синкать данные между БД
при записи сделать проекцию для БД где только идет чтение
а БД для чтения можно уже под UI сделать что бы проще было данные выбирать
Ой чет это как-то страшно звучит если честно. Но идея звучит круто и профессионально
AK
все это можно было бы сделать куда легче если бы у тебя были 2 базы: для записи, по сути мапинг сырые данные, и только БЛ с ними работает
и база для чтения
вопрос в том как только синкать данные между БД
при записи сделать проекцию для БД где только идет чтение
а БД для чтения можно уже под UI сделать что бы проще было данные выбирать
и база для чтения
вопрос в том как только синкать данные между БД
при записи сделать проекцию для БД где только идет чтение
а БД для чтения можно уже под UI сделать что бы проще было данные выбирать
репликация?
Ti
А зачем 2 базы-то
VA
репликация?
Похоже на то, но там столько тонкостей что аж страшно.
LK
репликация?
нет, ты не понял
у тебя две разные БД, дна для записи как удобно тебе работать с данными на бекенде
а другая БД больше ориентирована на UI то как удобно фронту получать данные
у тебя две разные БД, дна для записи как удобно тебе работать с данными на бекенде
а другая БД больше ориентирована на UI то как удобно фронту получать данные
LK
а репликацию можно уже на БД для чтения сделать
VA
А зачем 2 базы-то
Просто идея в том что если у тебя огромная нагрузка то будет такая ситуация что если база что-то пишет, она в этот момент не может читать. И нужно что бы одна писала а другая читала. И потом как-то делать sync их данных.