мне надо максимально усложнить реверс-инженеринг

Нода ведь на сервере . . .

Подход всё же является message passing и сохраняется вплоть до энтерпрайз ™️ паттернов архитектуры

там малинка, если не секрет?

уау, эмбедед решение на ноде

а есть какие-то варианты как-то защитить?

ну на чем умею

и при открытии формы выбора сервера конфиг и цены прямо на фронте уже и есть. теперь когда строиться бекенд на node express я вижу, что эти данные нужны на бекенде.... было бы норм их туда положить и при каждом открытии приложения тянуть с бекенда? не тяжеловато? конфиг занимает где то 100 строк... не тяжелый.. или лучше оставить на фронте.. и уже при сохранении формы пересылать на бек эти данные?

да разве два объекта по 3 поля это тяжело?

там больше около 100 строк.. ну кроме raid и hdd еще ОС, сеть ну итп... но слишком большим конфиг никогда не будет

чч спец

мб в базе такое лучше хранить, чтоб конфиг не хардкодить?

мб в базе такое лучше хранить, чтоб конфиг не хардкодить?

da. тоже подумал об этом

тем, что когда уйдёшь с проекта, начальство будет ходить и искать, где ж тарифы поправить)

тем более это при каждом открытии формы нужно..и при каждом сохранении ее же..

и при открытии формы выбора сервера конфиг и цены прямо на фронте уже и есть. теперь когда строиться бекенд на node express я вижу, что эти данные нужны на бекенде.... было бы норм их туда положить и при каждом открытии приложения тянуть с бекенда? не тяжеловато? конфиг занимает где то 100 строк... не тяжелый.. или лучше оставить на фронте.. и уже при сохранении формы пересылать на бек эти данные?

у нас при инициализации фронта, уходит запрос, который получает сетинги, конфиги. дальше их юзает

да

хранить на беке, запросить при инициализации и юзать

на фо нет стора?

редакс там. или что-то подобное

сто строчек кешировать

он же меняется раз в 5-летку (с.)

храни на беке, запроси при инициализации, положи в вуех

те не надо? тем более конфиг ведь на беке может и обновицца. а он уже в vuex закеширован.. или норм?

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

может быть не совсем точно сформулировал. объясню по другому. Начинается транзакция, создается первый заказ. База считает количество заказов данного пользователя - их 35. Ок, первый заказа будет с номером 2/35. Создает второй заказ, считает обшее количество заказов - их снова 35, так как первый заказ в данной транзакции еще не попал в базу. И следовательно у второго заказа тоже будет номер 2/35. ну и третий заказ аналогично запишется с номером 2/35.

так объяви переменную вначале, и делай инкремент после вставки

может быть не совсем точно сформулировал. объясню по другому. Начинается транзакция, создается первый заказ. База считает количество заказов данного пользователя - их 35. Ок, первый заказа будет с номером 2/35. Создает второй заказ, считает обшее количество заказов - их снова 35, так как первый заказ в данной транзакции еще не попал в базу. И следовательно у второго заказа тоже будет номер 2/35. ну и третий заказ аналогично запишется с номером 2/35.

берешь вначале кол-во заказов, и каждому заказу, который собираешься запушить даешь + 1

это работает если три заказа я записываю по отдельному sql запросу. но у меня один sql запрос, и внутри создаются записи через конструкцию WITH orders AS () INSERT INTO orders_table FROM orders;

есть нативный браузерный апи вебсокетов, часть HTML5, на нём вполне можно писать, если старое говно типа ИЕ 10- не надо поддерживать. socket.io, sock.js и прочие, обертывают нативное апи и также предоставляют фоллбэки на лонг поллинг и другие альтернативные способы. эти либы довольно полезные, но в целом без них вполне можно обойтись, поскольку в 2018 их практическая ценность (в плане фоллбэков) невелика, т.к. большинство браузеров вебсокеты прекрасно поддерживает с другой стороны, у них немного упрощённый синтаксис, хорошая документация и много примеров по этим либам, т.к. они много лет интенсивно использовались. socket.io вдобавок ещё и довольно легковесный, 18кб (sock.js 42k, для сравнения).

разве не подходит? https://www.quora.com/How-do-you-declare-a-variable-in-a-PostgreSQL-transaction

Есть какой-нибудь стандарт, по которому следует или не следует завершать операции точкой с запятой?

Есть какой-нибудь стандарт, по которому следует или не следует завершать операции точкой с запятой?

Есть какой-нибудь стандарт, по которому следует или не следует завершать операции точкой с запятой?

используй преттир и не парься

Есть какой-нибудь стандарт, по которому следует или не следует завершать операции точкой с запятой?

А как красиво из «a/b/c/d» получить [«a», «a/b», «a/b/c», «a/b/c/d»]? Какие по алгоритму идеи? reduce?

"a/b/c/d" .split("/") .reduce((acc, cur, i, whole) => [...acc, whole.slice(0, i+1).join("/")], []);