@nodejs_ru - страница 727 - Telegram web archive

Yan

и так повторять

Anonymous

Сервер отдает апдейты клиенту. Админ на веб-клиенте добавляет юниты с описанием и картинками. Юнит сохраняется/обновляется в базе с новым timestamp. Клиентская часть запрашивает обновления: отправляет timestamp последнего своего обновления на сервер => сервер ищет в базе последние юниты, timestamp которых больше того, что отправил клиент => генерирует новый архив с файлами Проблема в том, что если добовлять юниты нужно будет часто, а клиентов много, будет очень много архивов (одному клиенту может понадобиться апдейт, со вчерашнего дня; другому — месяц назад; третьему — год) И хранить все в кэше будет трудно (я предпологаю). Я вижу только: 1) Действительно все кешировать, но не знаю — делают ли так в таких случаях (кажется что объем кеша будет расти непомерно) 2) Тупо увеличивать количество инстансов с нагрузкой 3) Не знаю: а можно ли отдавать файлы каждый по отдельности ? Не в архиве ? Скажем нужно отдать 1000 картинок => пусть клиент обращается на s3 за ними сам. Так можно делать ?

Yan

последний вариант был бы самый простой, если на стороне клиента есть какой-нибудь сохраняльщик картинок

Yan

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

Yan

ну и там клиент применяет какую-либо прогу уже, которая все картинки автоматом грабит просто

Yan

но, на самом деле, в твоем кейся я склоняюсь к какой-то хитрой системе кэширования

Yan

потому что это позволит сильно снизить нагрузку на серв

Yan

но вряд ли я смогу надумать сейчас какой-то варик с кэшированием

Yan

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

Yan

хуева туча гет запросов разом

Anonymous

> @Yanislav_Igonin хуева туча гет запросов разом ага, вот я тоже об этом думал) На самом деле, просто узнать, что нет другого варианта кроме как кэшировать -> это уже ответ на мой вопрос. Спасибо! На всякий случай, чтоб не начать делать, а потом окажется что зря время потратил нужно было чтоб кто-то сказал "норм"). Мне просто казалось, что, быть может, есть какие-то волшебные способы (м.б. CDN что-то может предпринять в этом случае и т.п.). Но да, кэширование не выглядит так уж плохо (можно записывать промежутки timestamp_start - timestamp_end для которых архив является актульный или типа того)

Yan

если исключить какую-то магию, то, да, кэширование хитрое - самый стоящий способ)

Yan

вряд ли что-то можно лучше придумать для такого кейса

hamper 𓅝

хуева туча гет запросов разом

Браузеры обычно ограничиваются не более 5 параллельных запросов.

S 🇺🇦

Браузеры обычно ограничиваются не более 5 параллельных запросов.

Это верно для http 1.1, но не верно для http2 - во втором случае там по-моему вообще нет ограничения(либо оно достаточно высокое)

S 🇺🇦

> @Yanislav_Igonin хуева туча гет запросов разом ага, вот я тоже об этом думал) На самом деле, просто узнать, что нет другого варианта кроме как кэшировать -> это уже ответ на мой вопрос. Спасибо! На всякий случай, чтоб не начать делать, а потом окажется что зря время потратил нужно было чтоб кто-то сказал "норм"). Мне просто казалось, что, быть может, есть какие-то волшебные способы (м.б. CDN что-то может предпринять в этом случае и т.п.). Но да, кэширование не выглядит так уж плохо (можно записывать промежутки timestamp_start - timestamp_end для которых архив является актульный или типа того)

А почему бы не собирать все файлы-стримы в zip архив через модуль node-archiver?

hamper 𓅝

Это верно для http 1.1, но не верно для http2 - во втором случае там по-моему вообще нет ограничения(либо оно достаточно высокое)

Ну http2 просто через один сокет все тянет на сколько канал позволяет, но не флудит открытиями сокетов как 1 версия, что только снижает нагрузку.

Alexander

Есть ли смысо организовывать mvc модель в связке koa+mongoose? Лично я только модели делаю. А в роутах запрашиваю и модели данные

Evgeny

Дейли ремайндер о наших чатах: — Джаваскрипт: @js_ru, @react_js, @nodejs_ru, @vuejs_ru. Ну и @nodejs_jobs с @javascript_jobs. — Мобайл: @ios_ru, @android_ru, @reactnative_ru, @mobile_jobs — Дизайн: @uiux_ru, @uiux_jobs — Менеджмент и около: @agile_ru, @selfdev_ru — Девопс: @devops_ru, @docker_ru, @kubernetes_ru

Anonymous

а что там?

KIGM

Дейли ремайндер о наших чатах: — Джаваскрипт: @js_ru, @react_js, @nodejs_ru, @vuejs_ru. Ну и @nodejs_jobs с @javascript_jobs. — Мобайл: @ios_ru, @android_ru, @reactnative_ru, @mobile_jobs — Дизайн: @uiux_ru, @uiux_jobs — Менеджмент и около: @agile_ru, @selfdev_ru — Девопс: @devops_ru, @docker_ru, @kubernetes_ru

https://t.me/spbnodejs

Dmitrii

был у кого опыт с монорепозиториями? стоит ли пробовать?

Valeriy

Всем привет 🖐 Кто работает с Sails на TypeScript, нравится-удобно?)

Valeriy

Окей) а в чистом виде кто-нибудь юзает? Без тайп-скрипта.

Max

имхо сначала определиться с TS без TS важнее чем выбрать фреймворк

Max

а потом выбрать самые тайпскрипт ориентированные либы

Михаил Макарычев

Юзай koa2

Max

koa2 + TypeORM + redux

Max

смотря что человеку нужно от sails )

Dmitrii

koa2 + TypeORM + redux

что redux на сервере??

Max

для хранения оперативных данных

Max

ну и для самопального евентсорсинга

Max

прав пользователей например

Max

расшаренных структур данных, между юзерами

Max

чем больше в памяти, тем лучше

Max

типа кэша

Dmitrii

а потом костылять с рэдисом или стики сессиями, чтобы это все в кластере работало?

Max

долгий разговор )

Dreamerinnoise

базы данных слишком просто

Max

в общем eventsorcing, saga pattern, view / read model

Max

https://www.confluent.io/blog/making-sense-of-stream-processing/

Таймураз

Если проект мелкий и без планов масштабирования, то пускай

Max

если интересно, очень хорошо описывает проблемы баз данных и как их решать в распределённой системе

Max

стал юзать ОРМ только для не оперативных данных или для данных которые редко меняются

Max

эм... это другой уровень распределения

Max

распределённная бд - это одно, распределённое ПО это другое

Vladimir

Это как раз одно и то же

Max

дал линк выше

Max

неконсистенстность данных в ОЗУ и того, что в БД

Max

особенно, если серверов по обработке бизнес логики несколько, а БД одна

Max

выручает евент сорсинг, CQRS, евент-процессинг

Max

много названий у этих практик

Max

кэшами сложно разруливать. В основе приложения лог событий - БД с ормом становится вторичным сервисом

Max

однако сам лог событий, можно хранить в БД

Max

каждый маленькие сервис читает этот лог и имеет свой редакс стор

Max

редакс выступает как аггрегатор события в каждом сервисе

Max

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

Max

почти без рест апи

Max

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

Dima

ребята,юзаю mysql под node js и когда делаю неверный sql query, то сервер падает. Как можно предовратить постоянные краши такие?Как-то может кидать на 404 страничку,но не ложить сервер.

Sergey

ребята,юзаю mysql под node js и когда делаю неверный sql query, то сервер падает. Как можно предовратить постоянные краши такие?Как-то может кидать на 404 страничку,но не ложить сервер.

может отлавливать ошибки?

Dima

может отлавливать ошибки?

я отлавливаю ошибку,но сервер падает всеравно

Sergey

тут вроде телепатов нет

Max

process.on('uncachedException' / 'unhandledPromiseRejection', console.log)

Max

погугли 'uncachedException' / 'unhandledPromiseRejection' , может поможет локализовать причину падения

Vladimir

Скорее всего on('error' нужно где то

Anonymous

парни, такой вопрос: кто-нибудь загружал с помощью aws lambda файлы на s3 ? Как это делать правильно (можно ли просто юзать new AWS.s3().client.putObject) ?