Pull to refresh

Comments 49

Ну, Слава Богу! Наконец то русский BAAS!

Спасибо Вам! А то я уже на конференции по «облакам» хотел кинуть камень в огород ИТ индустрии :).
Давно надо сделать аналоги GC/Firebase, AWS. А то ФЗ не позволяет пользоваться, а альтернативы нет.

Из пожеланий: хочется не просто MongoDB, а промежуточный слой в виде RealTime DB, аналог Google Firebase и AWS DynamoDB.
Хочется микросервисов для обработки потоков данных, например, написал метод на JS, задеплоил к себе, на него система сформировала адрес, по которому этот метод вызывается. В AWS есть подобные сервисы, но пока в тестовом виде. Да и опять же ФЗ.

Желаю успешного развития!
Спасибо большое!

До уровня Google и Amazon будем дотягивать постепенно.

По микросервисам — сейчас есть возможность писать скрипт на JS, который можно вызвать через API с передачей пула параметров. Также можно настроить вызов по расписанию.

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

Еще из пожеланий: хостинг и сохранение файлов. В Firebase недавно появились эти сервисы. Хотелось бы видеть и у Вас.
У нас реализовано сохранение файлов с привязкой к полю в коллекции, с последующей возможностью получения временных ссылок на них. Время действия ссылки регулируется пользователем.

Хостинга пока нет, в планах.
Блин, один человек на полном серьёзе пишет «Наконец то русский BAAS!», другие ему тоже с полностью серьёзным лицом отвечают, что «будут постепенно дотягиваться до уровня Google и Amazon». Вы это всё что, на самом деле?
А что Вы видите в этом плохого? Битрикс написал в свое время хорошую статью о том, как они перевели свои приложения на AWS.
Теперь вышел ФЗ, и, я так понял, Битрикс вернул всё на российские датацентры.
А чем предлагаете пользоваться?
Я, кстати, думал, что BAAS запустит Яндекс или мэйл.ру.
Поэтому решение Scorocode стало приятной новостью.
Меня тоже резануло в ухо.

Имхо, речь о том, что подтянуть хотя бы частично до уровня Amazon, AWS по API.
Думаю речь не идет о масштабах их датацентров.
UFO just landed and posted this here
По серверным скриптам:
В ближайших планах сделать поддержку нодовских библиотек. Есть технические вопросы и вопросы безопасности, решаем.

По user:
Насчет некорректности токена не совсем понятно. Токен генерируется при операции login всегда. Можете пояснить, что не так?
logout не работает из SDK или при прямом вызове API?

По сбросу пароля:
Операции сброса пароля в API нет, поэтому и нет описания. Мы не были уверены в востребованности этой операции, поэтому не стади делать.

По слою данных «users»:
При регистрации вы можете указывать любые кастомные поля для пользователя, если они есть в коллекции users. В ответ на регистрацию приходит документ, содержащий эти поля и сгенерированный _id.
UFO just landed and posted this here
За сброс паролей спасибо, исправим.

По токену проверим. Если не сложно, напишите, пожалуйста, в поддержку ситуацию, при которой токен остается пустым.
UFO just landed and posted this here
Логику сброса пароля в Scorocode можно реализовать самостоятельно. Мы не стали сами придумывать реализацию, так как есть много разных вариантов.
UFO just landed and posted this here
Любой успешный сервис строится по принципу «сделай минимум и запусти», а потом уже развивается. Все Ваши мысли, и предложения многих других разработчиков нами учитываются в планах развития. Для этого существует техническая поддержка проекта, где, как Вы уже проверили на себе, ни одно замечание или предложение не пропадает.
UFO just landed and posted this here
Ну, из русских BaaS есть еще, как минимум, reindex.io. Так что не надо тут :) А вообще да — очень радует.
Ничего не понял. Что такое «backend»? У меня в продакшене инсталляция openstack'а. У него есть dashboard, который предоставляет веб-интерфейс. Сам dashboard ходит в API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на компьютах, компьют ходит в API, API ходит в API, API дёргает ABI, на выходе имеем сервис для клиента.

И где тут бэкэнд и куда тут ваше решение должно присоседиться?
В нашем случае backend — это:
  • организация доступа через API к структурированным данным;
  • возможность хранения и выполнения server-side скриптов с доступом к данным;
  • дополнительные методы API для авторизации пользователей, отправки разных типов сообщений, и т.п.

То есть фактически — это удобный конструктор структур данных и API с последующим хостингом.

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

Ваше решение более низкоуровневое, предназначено для создания системных облачных решений, наше — для решения прикладных задач.

Примером такой задачи может служить разработка мобильного приложения, которому необходимо хранить и обрабатывать данные на сервере.
Я понимаю, что у openstack'а уже всё написано. Я спрашиваю, какую его часть вы предлаете (хотя бы гипотетически) переписать с использованием вашей штуки?

Другой пример:

есть панелька управления для заказа космических полётов.

Состоит из мобильного приложения, веб-сайта и бота в IRC. Дальше там API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на ракетах, который ходит в API, API ходит в API, API дёргает ABI, который дёргает ABI, на выходе имеем ракету в космосе.

Какую часть этой штуки вы предлагаете заменить?
Все данные мобильного и WEB приложений, данные бота IRC (например, мы в одном из проектов храним в облаке данные бота Telegram), и все взаимодействие API — API в виде JS-скриптов.
то есть если мне нужно в рамках API между ракетой и стартовой площадкой слать телеметрию посредством udp-датаграмм, это надо делать через JS-скрипты?
Вы правы.
Для решения задач интеграции серверной части систем типа «заказ полета ракеты» и внешними сервисами типа «стартовая площадка» в идеологии облачного сервиса Scorocode применяются серверные JS-скрипты.
А в качестве транспортного протокола используется tcp с аяксом?
HTTPS POST-запросы, формат application/json.
Для телеметрии ракеты? А если потеряется ip-пакет и tcp устроит retransmit и следующая телеметрия застрянет на 40мс? А если из-за застрявшей телеметрии не пройдёт управляющая команда?
Привет, коллеги ;) Интересно наблюдать, как развиваются и взаимно интегрируются молодые сервисы. А мы планируем интеграции с партнёрскими сервисами для расширения функциональности платформы, чтобы сложные приложения стали проще в реализации.
Кстати, интересно, а есть ли у вас Business Process Management? На той же Camunda например? И так же есть ли поддержка интеграционных фреймворков? Тот же Apache Camel или еще что? Orienteer в beta уже поддерживает.
Привет.
С кем планируете интеграции в первую очередь?
Здравствуйте.

В ближайшее время будет интегрирован движок ABBYY для распознавания текстов и штрих-кодов. Чуть позже — боты Telegram, боты будут хоститься у нас, можно будет писать обработчики с доступом к данным приложения.

В будущем планируем интегрироваться с сервисами, которые смогут монетизироваться через наш встроенный магазин: CMS, BPMS, обработка изображений и т.п. Для этого активно смотрим по сторонам, особое внимание уделяя стартапам.
Раз вы пишете
в качестве отправной точки для Scorocode приняли базовую функциональность Parse с возможностью миграции данных из него в наше облако
то хотелось бы знать почему для миграции надо выбрать вас, а не одну из многочисленных альтернатив на Parse Open Server.
Ещё лично мне не понятно почему ограничили триггеры таким малым временем работы 500мс (если с тем же parse сравнить)
Приветствуем, yurash! Мы читали ранее ваш поверхностный обзор BaaS-сервисов от 2012 года, вы там писали, что планируете сделать расширенный. Надеемся, что попадём туда, если вы будете делать UPD.

Теперь к вопросам.
то хотелось бы знать почему для миграции надо выбрать вас, а не одну из многочисленных альтернатив на Parse Open Server.

Почему выбирать нас? Мы душевнее :) Но если серьезно, то мы как минимум предлагаем альтернативу Parse, а выбор – это ведь хорошо, не так ли? Мы пока не можем похвастаться кил-фичами, но что имеем сейчас для комфортной миграции:
  • Реализована функциональность Parse, позволяющая без особых усилий мигрироваться на нас – одна из ключевых задач на первый период market fit.
  • До нас реально донести потребности и пожелания по развитию платформы.
  • Есть документация на русском языке и реагирующая тех.поддержка.

Конечно, нам ещё предстоит развиваться, поэтому мы открыты к предложениям.

Ещё лично мне не понятно почему ограничили триггеры таким малым временем работы 500мс

Триггеры предназначены для работы со связанными данными (CRUD для зависимого документа в другой коллекции). Учитывая, что пользователь не любит ждать слишком долго ответа от сервера, то нет смысла делать их больше. Для всех более сложных операций, требующих значительного процессорного времени, есть CloudCode, который можно вызвать через API.
> Почему выбирать нас? Мы душевнее :) Но если серьезно, то мы как минимум предлагаем альтернативу Parse, а выбор – это ведь хорошо, не так ли?

Выбор — это всегда хорошо. Но выбор вашей платформы подразумевает переписывание фронтендов, а выбор других известных альтернатив Parse — нет.

Кроме того, Parse Server находится в open source и его развивает сообщество. В любой момент пользователь может уйти с альтернативного облачного решения на stand-alone, развернув свою инфраструктуру, с минимальными усилиями и изменениями в коде.

Если же пользователь выбрал вас, от уйти от вас уже не получится — ни с минимальными усилиями, ни с максимальными. Ни с какими. Пользователь будет зависеть от вас точно так же, как в свое время он зависел от Parse. Причем «за спиной» Parse стоял Facebook, что внушало определенную уверенность, пользователь был еще «не пуганный». Последующие же события существенно подорвали веру в BaaS вообще как в концепцию, и сейчас уже меньше желающих наступить на те же грабли.

В частности, поэтому многие из альтернативных решений Parse-хостинга дают пользователям куда больше свободы — например, Back4app дает прямой доступ к Mongo.

Стоит, наверное, упомянуть и то обстоятельство, что в случае, если переезжающий с Parse проект ориентирован главным образом на российского потребителя, то это как раз ваша целевая аудитория, но если ориентация на worldwide, то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
> то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.

Такой же как и итальянский хостинг, например.
)))
Видите ли, я мало знаю про Италию, так что вам виднее. ;)) Но в любом случае, хоститься там я не собирался.
ОК.
Испанский хостинг, австрийский, австралийский, шведский…

Да можно все страны мира называть как неподходящие для хостинга.
Выделяются только США, Ирландия (Google), Германия (Хетцнер), Франция (OVH) да Нидерланды.
Вы, может быть, уже раскроете мысль? Позиция «знаю, но не скажу, буду продолжать намеки», боюсь, не очень подходит для диалога.
Российский хостинг для проекта ориентированного на Россию — хороший выбор.
Для мирового проекта — дело не в РФ. Ваш выбор — США, Германия, Франция. Ну и почти все.
Вы просто повторили мысль, но не раскрыли. Впрочем, как хотите.
Простите, я не заинтересован разговаривать с непонятливыми людьми. Неполиткоректное слово на д или и не стоит здесь употреблять.
Не удивили — д'Артаньяны все такие. Вы не первый.
А еще интересно насчет миграции с Parse. Вот мы мигрировали, допустим — что дальше? Я так понимаю, фронтенд нужно переписывать полностью с вашими SDK? Если да, то приятного мало. Если нет, то, следовательно, ваши SDK на уровне API совместимы с Parse SDK. Но это догадки, а где прямые и явные утверждения? Вы говорите потенциальным пользователям — ребята, вы собираетесь куда-то переходить с Parse — давайте к нам! А дальше — молчок. Ведь это неизбежные вопросы, которые возникнут у каждого Parse-юзера, который ищет (если еще не нашел) альтернативу.
Спасибо за вопрос. Мы говорим о миграции данных с Parse на Scorocode. Фронт необходимо будет переписывать. Да, это не так удобно, как хотелось бы. Чтобы на уровне API быть совместимыми с Parse SDK, нужно по сути копировать его у себя, а у этого решения есть определённые юридические риски.
Спасибо за ответ. Вам определенно стОит более однозначно и понятно описать миграцию с Parse на сайте.
Там BSD лицензия — «бери и делай что хочешь, не забудь упомянуть меня».
Прочёл и захотелось что-то подобное попробовать сделать. Завтра попробуем с коллегами продумать архитектуру :)
Конкуренция — это хорошо. Делайте! :)
Sign up to leave a comment.