Меня всем устраивает а чем не устраивает можно самому дописать :) тесты ну тут сложнее меня фикстуры т.К. часть логики прямо в базе написана типа уникальности. И все равно сложные запросы проще на sql. Hql подобный язык не помешал бы но не уверен какая-то бы у него была бы скорость по orm

Есть что-то наподоибие https://www.npmjs.com/package/acl, только нормальный?) Что-то он вообще странный какой-то

Всем привет. Существует ли в природе того же уровня альтернатива sequelize. — Зачем/чем не устраивает? — вопрос для интересу и локальных тестов

Может bookshelf посмотреть? knex - хороший проект. Букшелф на его основе

Может bookshelf посмотреть? knex - хороший проект. Букшелф на его основе

Возьму на опыты

Есть что-то наподоибие https://www.npmjs.com/package/acl, только нормальный?) Что-то он вообще странный какой-то

Не хватает тарантула

Не хватает тарантула

а чем это поможет?

я видимо нашел одноименный npm модуль, а вы мне предложили-таки стек поменять?)

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

промисы?

writeStream

а ещё по socket.io вопросик. Есть страница. Как мне для каждого уникального пользователя сохранять сокет? io.on('connection', socket => { this.socket = socket; console.log('a user connected'); }); сейчас так. и понятно что this.socket видят все. Может можно какой-нибудь уникальный id присваивать? чтоб было this[id] = socket

writeStream

writeStream вроде в файл? или можно и на респонс как-то?

стримы пайпятся куда угодно

https://nodejs.org/api/stream.html

А для чего сохранять соединение с пользователем?

чтобы емитить ему события

при парсинге массива ссылок: this.socket.emit('url', item.url);

вот так делаю, чтоб пользователь видел какой урл парсится

Так может просто замыканием это передать?

> чтоб было this[id] = socket возникнут проблемы: 1. упадет процесс - потеряется все 2. не будет возможности масштабировать

как вариант через room & сохранять все активные rooms

http://socket.io/docs/rooms-and-namespaces/

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

Отдельная комнатв

Иначе у тебя биндинг на сервер

а как тогда запомнить в какой комнате пользователь?

любая база

ну это понятно :D я думал без бд обойтись

redis запили прямо на сервер

через redis и масштабирование можно делать (в пару строк)

жрет мало

а как в базе хранить тогда :) как идентиФИцировать пользователя то

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

просто на тачке nginx с regexp и upstream тогда спасает

@Dekeey загрузка на какой-нибудь удаленный сервер и rsync на машины? o_O

Я лично хз как правильно =( Зависит от кол-ва серверов и тд

@steppefox Спасибо. Интересно именно как это можно максимально просто масштабировать потом. Если просто грузить в папку, в базе писать имя файла и юзать rsync, при большом кол-ве файлов боюсь в inodes упереться

куку ему сгенерить

ну зависит от кол-ва файлов все же =(( Если у тебя какой-то контентный сервис, с большим количеством файлов, то возможно лучше вынести файлы на какой-нибудь файловый CDN и раздавать такую статику с него

что-то вроде rackspace заюзать? Сервис - петпроджект, с возможностью загрузки музыки, на будущее хотелось бы архитектуру продумать, в случае чего, спасибо еще раз

что-то вроде rackspace заюзать? Сервис - петпроджект, с возможностью загрузки музыки, на будущее хотелось бы архитектуру продумать, в случае чего, спасибо еще раз

Ну либо заюзать что-то вроде S3, или заводить свою ферму помоек и rsynкать всё не надо, т.к. есть база - шардируй по какому-нибудь половому признаку и имей 1 дубль по rsync например. Если не хочется вообще продумывать, то можно заюзать у MongoDB - GridFS, но тогда обязательно, без исключения используй CDN, т.к. GridFS даёт возможность масштабировать, но очень дорого, если сравнивать с тем что я описывал выше.

Вообще масштабирование статики довольно большая тема *__*

Это довольно серьезная архитектурная админская задача)

Тю на вас, где тут серьезность?

Вообще я бы уже советовал присматриваться к peer-to-peer аля btsync / ipfs + шардинг по какому-нибудь признаку в базе. Но сам в продакшене такой финт с ptp не делал.

Это довольно серьезная архитектурная админская задача)

Причем тут админы?

Вообще я бы уже советовал присматриваться к peer-to-peer аля btsync / ipfs + шардинг по какому-нибудь признаку в базе. Но сам в продакшене такой финт с ptp не делал.

btsync - тормоз и жрёт процессор

@pragus ну ок ок, просто я видел как этим занимались админы ;D сам я не разруливал статику

btsync - тормоз и жрёт процессор

Но если делать по 1 дублю, то как бы лучше чем rsyncать, меньше подводных же? Если конечно синхронизировать всё и везде, то да, конечно дорого.

@steppefox Спасибо. Интересно именно как это можно максимально просто масштабировать потом. Если просто грузить в папку, в базе писать имя файла и юзать rsync, при большом кол-ве файлов боюсь в inodes упереться

В лимит на число inodes не упрешься если использовать xfs/btrfs/zfs.

Но если делать по 1 дублю, то как бы лучше чем rsyncать, меньше подводных же? Если конечно синхронизировать всё и везде, то да, конечно дорого.

rsync тоже плохой вариант. Он бежит по дереву каталогов, составляет список и синкает. Если у тебя развесистая иерархия - будет долго и на это время все будет тормозить

rsync тоже плохой вариант. Он бежит по дереву каталогов, составляет список и синкает. Если у тебя развесистая иерархия - будет долго и на это время все будет тормозить

Я больше за консистентность данных переживаю, когда что-то ложится на плечи rsync. Сеть мигает, всё такое.

Я больше за консистентность данных переживаю, когда что-то ложится на плечи rsync. Сеть мигает, всё такое.

И? Там возможны варианты. rsync может применить изменения после передачи.

Парни, дичайшее спасибо всем за советы, думаю проще, наверное, заюзать готовые сервисы хранения, ибо не админ

Тогда S3

Тогда S3

В лице кого?

Всмысле?

Всмысле?

Где скачать s3?

вут?

вут?

Вот у меня есть сервер, я хочу s3. Что надо сделать?

s3 в данном контексте как я понимаю это amazon s3

заплатить амазону тот тебе даст апишечку

В чем смысл подъеба? все знают, что такое s3

заплатить амазону тот тебе даст апишечку

Рукалицо.жпг

ERROR: S client not available

У амазона есть в рф точки присутствия?

Нет

А файлы являются персональными данными?=)

Отлично, т.е. предлагается ~ 60-130ms rtt и бегать в Европу/штаты

Вы знаете что такое UTM-метки? Да – 95 ??????? 70% Нет – 40 ??? 30% ? 135 people voted so far. Poll closed.

Отлично, т.е. предлагается ~ 60-130ms rtt и бегать в Европу/штаты

Ну да

Ну да

Это ппц медленно. Особенно на мобильном инете.

Всмысле “медленно”? Это latency, какая разница мобильный-не мобильный

Тем более я думаю до европы не 60

Всмысле “медленно”? Это latency, какая разница мобильный-не мобильный

Пакетлосс

Ок, может быть

Но в России все равно ничего нет

Такого же плана

Тем более я думаю до европы не 60

50-60 ms из спб

До Праги

Но в России все равно ничего нет

Да тот же ngenix

Если уж про cdn

У s3 просто много готового тулинга, основное преимущество

https://www.ngenix.net/network/ru

Вот и толку тогда?

У s3 просто много готового тулинга, основное преимущество

ну, я думал хоть кто-то вспомнит про openstack swift

Ну он есть, да

Кто его готовит SaaS в РФ?

менее 50 ms

Кто его готовит SaaS в РФ?

причём тут saas? что мешает взять только object storage?

Речь о том чтобы не админить самому

ну зависит от кол-ва файлов все же =(( Если у тебя какой-то контентный сервис, с большим количеством файлов, то возможно лучше вынести файлы на какой-нибудь файловый CDN и раздавать такую статику с него

кстати, файлы всё равно надо будет хранить у себя. практически все cdn - это тупо кеш.

у себя хранить их можно в бекап-стораджах

кстати, файлы всё равно надо будет хранить у себя. практически все cdn - это тупо кеш.

ну не в случае с амазоном

Сори за оффтоп