Комментарии 57
А логику оставить на клиентской части? Не доверяю я таким вещам. Однако есть приложения, которым этих возможностей за глаза хватит…
0
Многие BaaS платформы предоставляют возможность добавить серверный код. Так что на клиент логика не выносится.
0
Часть логики действительно переходит на сторону клиента. Для определенного типа приложений это нежелательно или неприемлимо. Для этого мы работаем над возможностью добавления своего серверного кода в серверную часть приложения. Поддержка серверного кода будет доступна ориентировочно к концу июня. Stay tuned
+1
Круто! А что будет, если пользователь откроет консоль в хроме и насоздает миллион левых записей в базе? Есть какая-то защита от этого?
+3
Разработчик приложения имеет возможность запретить любую из АПИ операций используя нашу security систему. Например операция CREATE может быть запрещена для роли NotAuthenticatedUser, таким образом сценарий описанный в вопросе будет невозможен.
0
Для неавторизованных понятно. А как насчет обычного пользователя, у которого есть возможность, например, написать комментарий? Сможет ли он провернуть описанную мной махинацию?
+1
Может, запросто!
0
Для авторизированных пользователей тоже есть настройки security системы: через назначение ролей этому пользователю или напрямую указывая, какие права и какие операции данный пользователь может совершать.
0
Backendless API documentation is currently available only for iOS
А так еще один baas. Не вижу ничего особенного, чем вы лучше десятка других?
0
Документация доступна здесь, хотя она пока и далека от идеала. Выберите нужный вам СДК слева в панели.
По поводу отличий… Иметь возможность выбора хорошая штука, правда? Вообще-то в конце обзора и комментарием ниже все перечислено, не хотелось бы повторяться.
По поводу отличий… Иметь возможность выбора хорошая штука, правда? Вообще-то в конце обзора и комментарием ниже все перечислено, не хотелось бы повторяться.
0
Уже подсел на Parse.com
+2
Парс намного дороже, у нас АПИ вызовы безлимитно. Кроме-того, проще в использовании (время для старта в разы ниже), поддержка версионности на уровне приложения, фильтрация сообщений, флекс/эйр, видео стриминг… далее по списку в обзоре.
Какие фичи вам бы хотелось иметь, каких еще нет у Парса?
Какие фичи вам бы хотелось иметь, каких еще нет у Парса?
0
Что-то я не совсем понял насчет того, что Parse «намного дороже».
Если у меня 1 млн пользователей, которые делают по 1 запросу в месяц + я отправляю им по 1 push в месяц — у Parse я вписываюсь в бесплатный тариф. А у вас я должен отстегнуть $1000 за миллион пользователей + еще $700 за push-нотификации. Или я что-то не так считаю? :-\
Даже просто по тарифам: у Parse $0.07 за 1000 пушей против ваших $0.7. За гигабайт хранилища у Parse $0.2 против ваших $1.
Насчет «проще в использовании» — посмотрев документацию, не понял, чем у вас проще. Время для старта — куда уж ниже. Насчет версионности, фильтрации, стриминга — ничего не могу сказать, не пользовался пока.
Если у меня 1 млн пользователей, которые делают по 1 запросу в месяц + я отправляю им по 1 push в месяц — у Parse я вписываюсь в бесплатный тариф. А у вас я должен отстегнуть $1000 за миллион пользователей + еще $700 за push-нотификации. Или я что-то не так считаю? :-\
Даже просто по тарифам: у Parse $0.07 за 1000 пушей против ваших $0.7. За гигабайт хранилища у Parse $0.2 против ваших $1.
Насчет «проще в использовании» — посмотрев документацию, не понял, чем у вас проще. Время для старта — куда уж ниже. Насчет версионности, фильтрации, стриминга — ничего не могу сказать, не пользовался пока.
0
Это абсолютно нереальный сценарий. Ни одно приложение, которое делает 1 запрос в месяц не вырастет до 1,000,000 пользователей. Если этот же сценарий сделать более реалистичным, картина совершенно другая. Например, допустим приложение делает 1 АПИ запрос в день (это маловероятно, количество запросов намного выше). Таким образом за месяц будет сделано 30,000,000 запросов. С Парсом это будет стоить: 29,000,000 / 1000 * 0.07 = $2,030. у нас это будет стоить $1000, только за юзеров, то есть в 2 раза дешевле.
0
Для такого сценария у Parse покупается Pro-аккаунт за $199 c 15млн запросов и и для оставшихся 15млн платится 15000000 / 1000 * 0.05 = $750, что в сумме дает $949.
Вообще, платить за пользователей — это дикость, по-моему…
Цены на пуши, опять же, у вас в 10 раз выше, чем в бесплатном тарифе Parse (в Pro — выходит более, чем в 10 раз выше).
Я не ради холивара — просто утверждать, что Parse «намного дороже» не очень корректно в данном случае ;)
Вообще, платить за пользователей — это дикость, по-моему…
Цены на пуши, опять же, у вас в 10 раз выше, чем в бесплатном тарифе Parse (в Pro — выходит более, чем в 10 раз выше).
Я не ради холивара — просто утверждать, что Parse «намного дороже» не очень корректно в данном случае ;)
+1
Чтобы не быть голословным, давайте рассмотрим реальное приложение. Например пример от того же Парса. Если пройти по коду примера, то видно что при минимальном использовании приложения происходят следующие вызовы:
1. регистрация (1 раз)
2. логин (1 раз при открытии приложения)
3. сохранение поста (допустим 1 раз)
4. пост квери для получения точек (1 раз)
5. запрос на получение точек при смещении карты (допустим 3 раза за сеанс)
6. запрос на получение точек при изменении фильтра по дистанции (допустим 2 раза)
Итого: 9 вызовов. Так как регистрация происходит один раз, ее считать не будем, хотя для 1М пользователей, она добавит 1М АПИ вызовов. Т.е. ограничимся 8 вызовами. Допустим приложение используется ежедневно. Таким образом 1М пользователей за один день сгенерят 8М вызовов. За месяц это число будет 240М. Теперь ваша любимая часть, т.е. математика:
15М оплачено за $199. Оставшиеся 225М вызовов вам обойдутся в: 225,000,000 / 1000 * 0.05 = $11,250 + $199 = $11,449.
С бэкендлессом все проще, все та же круглая сумма в $1000…
1. регистрация (1 раз)
2. логин (1 раз при открытии приложения)
3. сохранение поста (допустим 1 раз)
4. пост квери для получения точек (1 раз)
5. запрос на получение точек при смещении карты (допустим 3 раза за сеанс)
6. запрос на получение точек при изменении фильтра по дистанции (допустим 2 раза)
Итого: 9 вызовов. Так как регистрация происходит один раз, ее считать не будем, хотя для 1М пользователей, она добавит 1М АПИ вызовов. Т.е. ограничимся 8 вызовами. Допустим приложение используется ежедневно. Таким образом 1М пользователей за один день сгенерят 8М вызовов. За месяц это число будет 240М. Теперь ваша любимая часть, т.е. математика:
15М оплачено за $199. Оставшиеся 225М вызовов вам обойдутся в: 225,000,000 / 1000 * 0.05 = $11,250 + $199 = $11,449.
С бэкендлессом все проще, все та же круглая сумма в $1000…
0
Я же написал «подсел». Это значит, что куча кода уже ориентировано на Parse. Можно переехать без больших проблем, но пока незачем.
0
Хорошо конечно, но то чего я не нашел ни в одном существующем сервисе:
— автоизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth), у тех что есть ограничего все Facebook и Twitter. Для русского сегмента не хватает как минимум вконтакта. Жду когда в http://deployd.com появится поддержка passport фреймворка. Умел бы — сам допилил.
— нормальный способ писать логику на сервере (побольше возможностей, дергать сторонние сервисы например, писать свои модули).
— поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK (это не сложно, но писать для того-же parse.com нет охоты, если и сделаю, то для deployd)
— поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либо. В том-же Parse это реализовано через CallBack, то-есть нужен кто-то кто бы эти функции периодически дергал
— экспорт и мержинг при изменении CoreData модели в BaaS.
Вот этого не хватает ни в одном существующем BaaS, а практически для каждого приложения это нужно, из тех, что я делаю.
— автоизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth), у тех что есть ограничего все Facebook и Twitter. Для русского сегмента не хватает как минимум вконтакта. Жду когда в http://deployd.com появится поддержка passport фреймворка. Умел бы — сам допилил.
— нормальный способ писать логику на сервере (побольше возможностей, дергать сторонние сервисы например, писать свои модули).
— поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK (это не сложно, но писать для того-же parse.com нет охоты, если и сделаю, то для deployd)
— поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либо. В том-же Parse это реализовано через CallBack, то-есть нужен кто-то кто бы эти функции периодически дергал
— экспорт и мержинг при изменении CoreData модели в BaaS.
Вот этого не хватает ни в одном существующем BaaS, а практически для каждого приложения это нужно, из тех, что я делаю.
+1
А чуть не забыл, еще поддержка LongPolling или постоянных соккетов. Не HTTP единым живут приложения.
0
еще одну функцию забыл: возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.
0
Спасибо за развернутый комментарий.
авторизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth)основа для этого уже есть, добавление OpenID и OAuth в планах.
нормальный способ писать логику на сервереработа над этим уже ведется (к концу июня)
поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDKпроясните пожалуйста, что именно СДК мог бы предоставить?
поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либотакже работаем над этим, мы рассматриваем эту часть как ветвь фичи «Поддержка серверного кода»
экспорт и мержинг при изменении CoreData модели в BaaSпожалуйста проясните юз-кейс. Что делает клиент, что ожидается от сервера?
поддержка LongPolling или постоянных соккетов. Не HTTP единым живут приложения.вполне реальное и реализуемое требование.
возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.согласен. Мы рассматриваем этот режим запуска сервиса как «Backendless Enterprise». Планируется предоставить возможность загрузки продукта ближе к концу лета.
0
поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK
проясните пожалуйста, что именно СДК мог бы предоставить?
Тяжело объяснить в двух словах, ну что-то вроде наподобие AFIncrementalStore или вообще на основе него. Для удобного переключения между бэкэндами.
экспорт и мержинг при изменении CoreData модели в BaaS
пожалуйста проясните юз-кейс. Что делает клиент, что ожидается от сервера?
Это нужно в процессе разработки, смысл в том, что модель данных приходится делать 2 раза. 1 раза в CoreData и второй раз в BaaS. Чтоб этот процесс исключить, можно просто один раз сделать модель данных и экспортировать её в BaaS, и так-же поступать со всеми изменениями. В Heroku есть такая штука, называется BuildPack.
возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.
согласен. Мы рассматриваем этот режим запуска сервиса как «Backendless Enterprise». Планируется предоставить возможность загрузки продукта ближе к концу лета.
Вопрос как раз не в том, чтоб разворачивать это у себя на сервере. Суть в том, чтоб быстро это запустить на своей локальной машине только для разработки, а потом одной командой деплоить это на сервер. В Deployd посмотрите, там это основной способ работы. Это очень удобно, если над проектом работает один разработчик. Он работает со своей локальной копией, которая быстро работает без сети через lo интерфейс. А задеплоены все версии, которые уже были выпущены. На них работают тестеры или боевые релизы.
0
Решил попробовать.
1. Зарегался.
2. Создал приложение.
3. Перешёл в Data.
4. Решил добавить таблицу, кликнул «Добавить таблицу». Ввёл название.
5. Появилось две строки (представляющие колонки) update, created.
6. Попробовал изменить имя колонки. По клику на поле появляется календарь о_0. Видимо, из-за того, что тип колонки стоит DATETIME. Суть в том, что ввести словесное имя для такой колонки не представляется возможным. Единственный выход — ставить тип «Строка», менять имя и возвращать тип обратно. При этом, у created невозможно поменять тип.
ЧЯДНТ? Или что я неправильно понял?
1. Зарегался.
2. Создал приложение.
3. Перешёл в Data.
4. Решил добавить таблицу, кликнул «Добавить таблицу». Ввёл название.
5. Появилось две строки (представляющие колонки) update, created.
6. Попробовал изменить имя колонки. По клику на поле появляется календарь о_0. Видимо, из-за того, что тип колонки стоит DATETIME. Суть в том, что ввести словесное имя для такой колонки не представляется возможным. Единственный выход — ставить тип «Строка», менять имя и возвращать тип обратно. При этом, у created невозможно поменять тип.
ЧЯДНТ? Или что я неправильно понял?
0
p.s. Ради теста, решил создать ещё одну таблицу. Так в ней и у update нельзя поменять тип.
0
Колонки «updated» и «created» являются системными и не подлежат измениям (переименование или изменение значений) разработчиком. Бекендлесс сам изменяет тайм стемп этих колонок когда объект сохраняется (created) или происходит изменение значений колонок. (updated).
0
Меня вот что смущает. Везде в подобных сервисах какой-то проприетарный формат хранения данных. Таким образом я у вас захощусь, заведу данные. Вы вдруг накроетесь (ну всякое в жизни бывает).
И что мне после этого делать? Писать бэкенд с нуля?
Почему бы не сделать открытый формат и монетизировать инфраструктуру вокруг него? Таким бы я лично пользовался.
Ну и предложение — запилить бибилиотеку интеграции для линейки mono (monotouch/monodroid). Раз уж мы ведем речь о независимости от платформы, то это очень логичный шаг.
И что мне после этого делать? Писать бэкенд с нуля?
Почему бы не сделать открытый формат и монетизировать инфраструктуру вокруг него? Таким бы я лично пользовался.
Ну и предложение — запилить бибилиотеку интеграции для линейки mono (monotouch/monodroid). Раз уж мы ведем речь о независимости от платформы, то это очень логичный шаг.
0
Таким образом я у вас захощусь, заведу данные. Вы вдруг накроетесь (ну всякое в жизни бывает). И что мне после этого делать? Писать бэкенд с нуля?Вам будет достаточно делать периодический экспорт своих данных.
Почему бы не сделать открытый формат и монетизировать инфраструктуру вокруг него? Таким бы я лично пользовался.Структура и формат данных, который используется у нас внутри, концептуально не должна иметь никакого значения, поскольку вы можете экспортировать данные в любой момент.
Ну и предложение — запилить бибилиотеку интеграции для линейки mono (monotouch/monodroid).Для любого типа клиента, для которого мы не публикуем нативную библиотеку, вы можете использовать РЕСТ АПИ.
0
>Структура и формат данных, который используется у нас внутри, концептуально не должна иметь никакого значения, поскольку вы можете экспортировать данные в любой момент.
Ну смотрите. Я данные экспортнул. А дальше что мне с ними делать? Приложение у меня умеет общаться только с вашим сервером по проприетарному АПИ. Т.е. мне нужно либо переписывать полностью это общение для использования новой базы, либо писать свою прослойку и самостоятельно реализовывать ваше АПИ поверх какого-либо хранилища данных.
Оба варианта мягко говоря не самые простые.
Ну смотрите. Я данные экспортнул. А дальше что мне с ними делать? Приложение у меня умеет общаться только с вашим сервером по проприетарному АПИ. Т.е. мне нужно либо переписывать полностью это общение для использования новой базы, либо писать свою прослойку и самостоятельно реализовывать ваше АПИ поверх какого-либо хранилища данных.
Оба варианта мягко говоря не самые простые.
0
Оба варианта мягко говоря не самые простые.Мы (и вы) не одиноки в подобной ситуации. Допустим вы работаете с hibernate, как легко вы можете перейти на другой персистенс фреймворк? Совершенно нелегкая задача. Допустим вы работаете с MySQL и решили перейти на Oracle. Насколько это будет просто? Также непростая задача. Среди BaaS провайдеров нет единого стандарта по АПИ или по формату хранения данных. Возможно ли переписать программу которая работает с Parse и перевести ее на Backendless? Безусловно! Будет ли это просто? Это зависит от сложности программы. Тоже самое будет правдой и в обратную сторону. Здесь чудес никаких быть не может.
0
Допустим, я работаю с MySQL. Накрылся один провайдер — залил бекап к его соседу и продолжаю работать дальше. Когда такое станет возможно с облачными платформами — с ними можно будет серьезно иметь дело. Пока же это для всяких игрушечных приложений и легких кейсов, типа организации простой авторизации, без наворачивания функционала.
0
Как я понимаю, тут вопрос выбора: хочешь пользоваться или нет! Хочешь пользоваться — принимай правила игры.
Основная идея, как мне кажется — возможность быстро попробовать/протестировать приложение. Если дело пошло, то можно переписать весь бекэнд под себя и экспортировать данные из сервиса. Вуаля!
Основная идея, как мне кажется — возможность быстро попробовать/протестировать приложение. Если дело пошло, то можно переписать весь бекэнд под себя и экспортировать данные из сервиса. Вуаля!
0
как-то у вас с кодировками полный ахтунг :(
русские буквы превращаются в феерические вопросительные знаки
русские буквы превращаются в феерические вопросительные знаки
0
Полноценный бэкенд это никогда не заменит. И это хорошо.
0
И это хорошо.
Для серверных разработчиков, да, пока хорошо — работа будет. Но, в целом, тренд идёт в эту сторону. Рано или поздно станет плохо.
0
Полноценный бэкенд это никогда не заменит.Что вы вкладываете в понятие «полноценный бэкенд»?
0
Именно то и вкладываю. Используя коробочное решение упираешься в ограничения этого черного ящика(коробочного решения). А дальше хоть вешайся.
0
Как минимум 50 000 разработчиков думают иначе. Что-то подсказывает мне, что количество самых популярных юзкейсов для бэкенда не составляет бесконечное множество и скоро будет покрыто рынком. С какими ограничениями вы столкнулись в своих проектах?
0
а почему в данной статье нет примеров кода для Flex / Action Script?
0
Были продемонстрированы самые популярные. Скачайте пожалуста СДК для флекса, там есть примеры для каждого АПИ
0
Задам нубский вопрос, а сайт на основе вашего БааС можно сделать?
0
А все вопросы связанные с хранением и обработкой персональных данных и соблюдением закона о ПД вы тоже сами решаете?
0
0
Я извиняюсь, а есть нужен XHR, как обходится cross origin?
0
Извините пожалуйста, а можно писать кодом? А то мне уже надоел этот конструктор, непонятно ничего. Пока Parse для меня лучше только тем, что там нормальный понятный nodejs, а не визуальное программирование мышкой, как в backendless…
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Свой облачный бэкенд в одну строчку кода. Обзор BaaS платформы «Backendless»