Комментарии 49
Ну, Слава Богу! Наконец то русский BAAS!
Спасибо Вам! А то я уже на конференции по «облакам» хотел кинуть камень в огород ИТ индустрии :).
Давно надо сделать аналоги GC/Firebase, AWS. А то ФЗ не позволяет пользоваться, а альтернативы нет.
Из пожеланий: хочется не просто MongoDB, а промежуточный слой в виде RealTime DB, аналог Google Firebase и AWS DynamoDB.
Хочется микросервисов для обработки потоков данных, например, написал метод на JS, задеплоил к себе, на него система сформировала адрес, по которому этот метод вызывается. В AWS есть подобные сервисы, но пока в тестовом виде. Да и опять же ФЗ.
Желаю успешного развития!
Спасибо Вам! А то я уже на конференции по «облакам» хотел кинуть камень в огород ИТ индустрии :).
Давно надо сделать аналоги GC/Firebase, AWS. А то ФЗ не позволяет пользоваться, а альтернативы нет.
Из пожеланий: хочется не просто MongoDB, а промежуточный слой в виде RealTime DB, аналог Google Firebase и AWS DynamoDB.
Хочется микросервисов для обработки потоков данных, например, написал метод на JS, задеплоил к себе, на него система сформировала адрес, по которому этот метод вызывается. В AWS есть подобные сервисы, но пока в тестовом виде. Да и опять же ФЗ.
Желаю успешного развития!
Спасибо большое!
До уровня Google и Amazon будем дотягивать постепенно.
По микросервисам — сейчас есть возможность писать скрипт на JS, который можно вызвать через API с передачей пула параметров. Также можно настроить вызов по расписанию.
Мы очень надеемся активно развиваться вместе с сообществом разработчиков, готовы слушать пожелания и реализовывать востребованные функции.
До уровня Google и Amazon будем дотягивать постепенно.
По микросервисам — сейчас есть возможность писать скрипт на JS, который можно вызвать через API с передачей пула параметров. Также можно настроить вызов по расписанию.
Мы очень надеемся активно развиваться вместе с сообществом разработчиков, готовы слушать пожелания и реализовывать востребованные функции.
Еще из пожеланий: хостинг и сохранение файлов. В Firebase недавно появились эти сервисы. Хотелось бы видеть и у Вас.
Блин, один человек на полном серьёзе пишет «Наконец то русский BAAS!», другие ему тоже с полностью серьёзным лицом отвечают, что «будут постепенно дотягиваться до уровня Google и Amazon». Вы это всё что, на самом деле?
А что Вы видите в этом плохого? Битрикс написал в свое время хорошую статью о том, как они перевели свои приложения на AWS.
Теперь вышел ФЗ, и, я так понял, Битрикс вернул всё на российские датацентры.
А чем предлагаете пользоваться?
Я, кстати, думал, что BAAS запустит Яндекс или мэйл.ру.
Поэтому решение Scorocode стало приятной новостью.
Теперь вышел ФЗ, и, я так понял, Битрикс вернул всё на российские датацентры.
А чем предлагаете пользоваться?
Я, кстати, думал, что BAAS запустит Яндекс или мэйл.ру.
Поэтому решение Scorocode стало приятной новостью.
Меня тоже резануло в ухо.
Имхо, речь о том, что подтянуть хотя бы частично до уровня Amazon, AWS по API.
Думаю речь не идет о масштабах их датацентров.
Имхо, речь о том, что подтянуть хотя бы частично до уровня Amazon, AWS по API.
Думаю речь не идет о масштабах их датацентров.
НЛО прилетело и опубликовало эту надпись здесь
По серверным скриптам:
В ближайших планах сделать поддержку нодовских библиотек. Есть технические вопросы и вопросы безопасности, решаем.
По user:
Насчет некорректности токена не совсем понятно. Токен генерируется при операции login всегда. Можете пояснить, что не так?
logout не работает из SDK или при прямом вызове API?
По сбросу пароля:
Операции сброса пароля в API нет, поэтому и нет описания. Мы не были уверены в востребованности этой операции, поэтому не стади делать.
По слою данных «users»:
При регистрации вы можете указывать любые кастомные поля для пользователя, если они есть в коллекции users. В ответ на регистрацию приходит документ, содержащий эти поля и сгенерированный _id.
В ближайших планах сделать поддержку нодовских библиотек. Есть технические вопросы и вопросы безопасности, решаем.
По user:
Насчет некорректности токена не совсем понятно. Токен генерируется при операции login всегда. Можете пояснить, что не так?
logout не работает из SDK или при прямом вызове API?
По сбросу пароля:
Операции сброса пароля в API нет, поэтому и нет описания. Мы не были уверены в востребованности этой операции, поэтому не стади делать.
По слою данных «users»:
При регистрации вы можете указывать любые кастомные поля для пользователя, если они есть в коллекции users. В ответ на регистрацию приходит документ, содержащий эти поля и сгенерированный _id.
НЛО прилетело и опубликовало эту надпись здесь
За сброс паролей спасибо, исправим.
По токену проверим. Если не сложно, напишите, пожалуйста, в поддержку ситуацию, при которой токен остается пустым.
По токену проверим. Если не сложно, напишите, пожалуйста, в поддержку ситуацию, при которой токен остается пустым.
НЛО прилетело и опубликовало эту надпись здесь
Логику сброса пароля в Scorocode можно реализовать самостоятельно. Мы не стали сами придумывать реализацию, так как есть много разных вариантов.
НЛО прилетело и опубликовало эту надпись здесь
Любой успешный сервис строится по принципу «сделай минимум и запусти», а потом уже развивается. Все Ваши мысли, и предложения многих других разработчиков нами учитываются в планах развития. Для этого существует техническая поддержка проекта, где, как Вы уже проверили на себе, ни одно замечание или предложение не пропадает.
Ну, из русских BaaS есть еще, как минимум, reindex.io. Так что не надо тут :) А вообще да — очень радует.
Ничего не понял. Что такое «backend»? У меня в продакшене инсталляция openstack'а. У него есть dashboard, который предоставляет веб-интерфейс. Сам dashboard ходит в API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на компьютах, компьют ходит в API, API ходит в API, API дёргает ABI, на выходе имеем сервис для клиента.
И где тут бэкэнд и куда тут ваше решение должно присоседиться?
И где тут бэкэнд и куда тут ваше решение должно присоседиться?
В нашем случае backend — это:
То есть фактически — это удобный конструктор структур данных и API с последующим хостингом.
Openstack используется для создания инфраструктурных облачных сервисов и облачных хранилищ. С его помощью у нас организовано хранение файлов.
Ваше решение более низкоуровневое, предназначено для создания системных облачных решений, наше — для решения прикладных задач.
Примером такой задачи может служить разработка мобильного приложения, которому необходимо хранить и обрабатывать данные на сервере.
- организация доступа через API к структурированным данным;
- возможность хранения и выполнения server-side скриптов с доступом к данным;
- дополнительные методы API для авторизации пользователей, отправки разных типов сообщений, и т.п.
То есть фактически — это удобный конструктор структур данных и API с последующим хостингом.
Openstack используется для создания инфраструктурных облачных сервисов и облачных хранилищ. С его помощью у нас организовано хранение файлов.
Ваше решение более низкоуровневое, предназначено для создания системных облачных решений, наше — для решения прикладных задач.
Примером такой задачи может служить разработка мобильного приложения, которому необходимо хранить и обрабатывать данные на сервере.
Я понимаю, что у openstack'а уже всё написано. Я спрашиваю, какую его часть вы предлаете (хотя бы гипотетически) переписать с использованием вашей штуки?
Другой пример:
есть панелька управления для заказа космических полётов.
Состоит из мобильного приложения, веб-сайта и бота в IRC. Дальше там API. API ходит в API, API ходит в API, API ходит в API, API пересылает запросы через rabbitmq в сервис на ракетах, который ходит в API, API ходит в API, API дёргает ABI, который дёргает ABI, на выходе имеем ракету в космосе.
Какую часть этой штуки вы предлагаете заменить?
Другой пример:
есть панелька управления для заказа космических полётов.
Состоит из мобильного приложения, веб-сайта и бота в 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-скрипты?
Привет, практически коллегам:) У нас пользователи Orienteer (open source Business Application Platform) используют его в совокупности с Docker (+масштабирование через Docker Cloud) для backend приложений и сайтов.
Привет, коллеги ;) Интересно наблюдать, как развиваются и взаимно интегрируются молодые сервисы. А мы планируем интеграции с партнёрскими сервисами для расширения функциональности платформы, чтобы сложные приложения стали проще в реализации.
Кстати, интересно, а есть ли у вас Business Process Management? На той же Camunda например? И так же есть ли поддержка интеграционных фреймворков? Тот же Apache Camel или еще что? Orienteer в beta уже поддерживает.
Привет.
С кем планируете интеграции в первую очередь?
С кем планируете интеграции в первую очередь?
Здравствуйте.
В ближайшее время будет интегрирован движок ABBYY для распознавания текстов и штрих-кодов. Чуть позже — боты Telegram, боты будут хоститься у нас, можно будет писать обработчики с доступом к данным приложения.
В будущем планируем интегрироваться с сервисами, которые смогут монетизироваться через наш встроенный магазин: CMS, BPMS, обработка изображений и т.п. Для этого активно смотрим по сторонам, особое внимание уделяя стартапам.
В ближайшее время будет интегрирован движок ABBYY для распознавания текстов и штрих-кодов. Чуть позже — боты Telegram, боты будут хоститься у нас, можно будет писать обработчики с доступом к данным приложения.
В будущем планируем интегрироваться с сервисами, которые смогут монетизироваться через наш встроенный магазин: CMS, BPMS, обработка изображений и т.п. Для этого активно смотрим по сторонам, особое внимание уделяя стартапам.
Раз вы пишете
Ещё лично мне не понятно почему ограничили триггеры таким малым временем работы 500мс (если с тем же parse сравнить)
в качестве отправной точки для Scorocode приняли базовую функциональность Parse с возможностью миграции данных из него в наше облакото хотелось бы знать почему для миграции надо выбрать вас, а не одну из многочисленных альтернатив на Parse Open Server.
Ещё лично мне не понятно почему ограничили триггеры таким малым временем работы 500мс (если с тем же parse сравнить)
Приветствуем, yurash! Мы читали ранее ваш поверхностный обзор BaaS-сервисов от 2012 года, вы там писали, что планируете сделать расширенный. Надеемся, что попадём туда, если вы будете делать UPD.
Теперь к вопросам.
Почему выбирать нас? Мы душевнее :) Но если серьезно, то мы как минимум предлагаем альтернативу Parse, а выбор – это ведь хорошо, не так ли? Мы пока не можем похвастаться кил-фичами, но что имеем сейчас для комфортной миграции:
Конечно, нам ещё предстоит развиваться, поэтому мы открыты к предложениям.
Триггеры предназначены для работы со связанными данными (CRUD для зависимого документа в другой коллекции). Учитывая, что пользователь не любит ждать слишком долго ответа от сервера, то нет смысла делать их больше. Для всех более сложных операций, требующих значительного процессорного времени, есть CloudCode, который можно вызвать через API.
Теперь к вопросам.
то хотелось бы знать почему для миграции надо выбрать вас, а не одну из многочисленных альтернатив на 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, то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
Выбор — это всегда хорошо. Но выбор вашей платформы подразумевает переписывание фронтендов, а выбор других известных альтернатив Parse — нет.
Кроме того, Parse Server находится в open source и его развивает сообщество. В любой момент пользователь может уйти с альтернативного облачного решения на stand-alone, развернув свою инфраструктуру, с минимальными усилиями и изменениями в коде.
Если же пользователь выбрал вас, от уйти от вас уже не получится — ни с минимальными усилиями, ни с максимальными. Ни с какими. Пользователь будет зависеть от вас точно так же, как в свое время он зависел от Parse. Причем «за спиной» Parse стоял Facebook, что внушало определенную уверенность, пользователь был еще «не пуганный». Последующие же события существенно подорвали веру в BaaS вообще как в концепцию, и сейчас уже меньше желающих наступить на те же грабли.
В частности, поэтому многие из альтернативных решений Parse-хостинга дают пользователям куда больше свободы — например, Back4app дает прямой доступ к Mongo.
Стоит, наверное, упомянуть и то обстоятельство, что в случае, если переезжающий с Parse проект ориентирован главным образом на российского потребителя, то это как раз ваша целевая аудитория, но если ориентация на worldwide, то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
> то в нынешних политических условиях хостинг бэкенда в России — это, в общем-то, минус.
Такой же как и итальянский хостинг, например.
)))
Такой же как и итальянский хостинг, например.
)))
Видите ли, я мало знаю про Италию, так что вам виднее. ;)) Но в любом случае, хоститься там я не собирался.
ОК.
Испанский хостинг, австрийский, австралийский, шведский…
Да можно все страны мира называть как неподходящие для хостинга.
Выделяются только США, Ирландия (Google), Германия (Хетцнер), Франция (OVH) да Нидерланды.
Испанский хостинг, австрийский, австралийский, шведский…
Да можно все страны мира называть как неподходящие для хостинга.
Выделяются только США, Ирландия (Google), Германия (Хетцнер), Франция (OVH) да Нидерланды.
А еще интересно насчет миграции с Parse. Вот мы мигрировали, допустим — что дальше? Я так понимаю, фронтенд нужно переписывать полностью с вашими SDK? Если да, то приятного мало. Если нет, то, следовательно, ваши SDK на уровне API совместимы с Parse SDK. Но это догадки, а где прямые и явные утверждения? Вы говорите потенциальным пользователям — ребята, вы собираетесь куда-то переходить с Parse — давайте к нам! А дальше — молчок. Ведь это неизбежные вопросы, которые возникнут у каждого Parse-юзера, который ищет (если еще не нашел) альтернативу.
Прочёл и захотелось что-то подобное попробовать сделать. Завтра попробуем с коллегами продумать архитектуру :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор новорождённой платформы Scorocode