Свой облачный бэкенд в одну строчку кода. Обзор BaaS платформы «Backendless»

[KwI]

А логику оставить на клиентской части? Не доверяю я таким вещам. Однако есть приложения, которым этих возможностей за глаза хватит…

[micherr]

Многие BaaS платформы предоставляют возможность добавить серверный код. Так что на клиент логика не выносится.

[backendless]

Часть логики действительно переходит на сторону клиента. Для определенного типа приложений это нежелательно или неприемлимо. Для этого мы работаем над возможностью добавления своего серверного кода в серверную часть приложения. Поддержка серверного кода будет доступна ориентировочно к концу июня. Stay tuned

[KwI]

А вот это значимое и приятное уточнение! Спасибо!

[backendless]

Всегда пожалуйста. Ждем отзывов, замечаний и пожеланий.

[batment]

Круто! А что будет, если пользователь откроет консоль в хроме и насоздает миллион левых записей в базе? Есть какая-то защита от этого?

[backendless]

Разработчик приложения имеет возможность запретить любую из АПИ операций используя нашу security систему. Например операция CREATE может быть запрещена для роли NotAuthenticatedUser, таким образом сценарий описанный в вопросе будет невозможен.

[batment]

Для неавторизованных понятно. А как насчет обычного пользователя, у которого есть возможность, например, написать комментарий? Сможет ли он провернуть описанную мной махинацию?

[ha2bj]

Может, запросто!

[backendless]

Кстати, поделитесь пожалуйста опытом. Как вы сами решили эту задачу для своего бэкенда?

[kSx]

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

[backendless]

Для авторизированных пользователей тоже есть настройки security системы: через назначение ролей этому пользователю или напрямую указывая, какие права и какие операции данный пользователь может совершать.

[akira]

Backendless API documentation is currently available only for iOS

А так еще один baas. Не вижу ничего особенного, чем вы лучше десятка других?

[backendless]

Документация доступна здесь, хотя она пока и далека от идеала. Выберите нужный вам СДК слева в панели.

По поводу отличий… Иметь возможность выбора хорошая штука, правда? Вообще-то в конце обзора и комментарием ниже все перечислено, не хотелось бы повторяться.

[egormerkushev]

Уже подсел на Parse.com

[backendless]

Парс намного дороже, у нас АПИ вызовы безлимитно. Кроме-того, проще в использовании (время для старта в разы ниже), поддержка версионности на уровне приложения, фильтрация сообщений, флекс/эйр, видео стриминг… далее по списку в обзоре.

Какие фичи вам бы хотелось иметь, каких еще нет у Парса?

[xZenon]

Что-то я не совсем понял насчет того, что Parse «намного дороже».
Если у меня 1 млн пользователей, которые делают по 1 запросу в месяц + я отправляю им по 1 push в месяц — у Parse я вписываюсь в бесплатный тариф. А у вас я должен отстегнуть $1000 за миллион пользователей + еще $700 за push-нотификации. Или я что-то не так считаю? :-\

Даже просто по тарифам: у Parse $0.07 за 1000 пушей против ваших $0.7. За гигабайт хранилища у Parse $0.2 против ваших $1.

Насчет «проще в использовании» — посмотрев документацию, не понял, чем у вас проще. Время для старта — куда уж ниже. Насчет версионности, фильтрации, стриминга — ничего не могу сказать, не пользовался пока.

[backendless]

Это абсолютно нереальный сценарий. Ни одно приложение, которое делает 1 запрос в месяц не вырастет до 1,000,000 пользователей. Если этот же сценарий сделать более реалистичным, картина совершенно другая. Например, допустим приложение делает 1 АПИ запрос в день (это маловероятно, количество запросов намного выше). Таким образом за месяц будет сделано 30,000,000 запросов. С Парсом это будет стоить: 29,000,000 / 1000 * 0.07 = $2,030. у нас это будет стоить $1000, только за юзеров, то есть в 2 раза дешевле.

[xZenon]

Для такого сценария у Parse покупается Pro-аккаунт за $199 c 15млн запросов и и для оставшихся 15млн платится 15000000 / 1000 * 0.05 = $750, что в сумме дает $949.
Вообще, платить за пользователей — это дикость, по-моему…
Цены на пуши, опять же, у вас в 10 раз выше, чем в бесплатном тарифе Parse (в Pro — выходит более, чем в 10 раз выше).
Я не ради холивара — просто утверждать, что Parse «намного дороже» не очень корректно в данном случае ;)

[backendless]

Чтобы не быть голословным, давайте рассмотрим реальное приложение. Например пример от того же Парса. Если пройти по коду примера, то видно что при минимальном использовании приложения происходят следующие вызовы:
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…

[xZenon]

Убедили, спасибо.

[egormerkushev]

Я же написал «подсел». Это значит, что куча кода уже ориентировано на Parse. Можно переехать без больших проблем, но пока незачем.

[rule]

Хорошо конечно, но то чего я не нашел ни в одном существующем сервисе:
— автоизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth), у тех что есть ограничего все Facebook и Twitter. Для русского сегмента не хватает как минимум вконтакта. Жду когда в http://deployd.com появится поддержка passport фреймворка. Умел бы — сам допилил.
— нормальный способ писать логику на сервере (побольше возможностей, дергать сторонние сервисы например, писать свои модули).
— поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK (это не сложно, но писать для того-же parse.com нет охоты, если и сделаю, то для deployd)
— поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либо. В том-же Parse это реализовано через CallBack, то-есть нужен кто-то кто бы эти функции периодически дергал
— экспорт и мержинг при изменении CoreData модели в BaaS.

Вот этого не хватает ни в одном существующем BaaS, а практически для каждого приложения это нужно, из тех, что я делаю.

[rule]

А чуть не забыл, еще поддержка LongPolling или постоянных соккетов. Не HTTP единым живут приложения.

[rule]

еще одну функцию забыл: возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.

[backendless]

Спасибо за развернутый комментарий.

авторизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth)

основа для этого уже есть, добавление OpenID и OAuth в планах.

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

работа над этим уже ведется (к концу июня)

поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK

проясните пожалуйста, что именно СДК мог бы предоставить?

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

также работаем над этим, мы рассматриваем эту часть как ветвь фичи «Поддержка серверного кода»

экспорт и мержинг при изменении CoreData модели в BaaS

пожалуйста проясните юз-кейс. Что делает клиент, что ожидается от сервера?

поддержка LongPolling или постоянных соккетов. Не HTTP единым живут приложения.

вполне реальное и реализуемое требование.

возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.

согласен. Мы рассматриваем этот режим запуска сервиса как «Backendless Enterprise». Планируется предоставить возможность загрузки продукта ближе к концу лета.

[rule]

поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK
проясните пожалуйста, что именно СДК мог бы предоставить?

Тяжело объяснить в двух словах, ну что-то вроде наподобие AFIncrementalStore или вообще на основе него. Для удобного переключения между бэкэндами.

экспорт и мержинг при изменении CoreData модели в BaaS
пожалуйста проясните юз-кейс. Что делает клиент, что ожидается от сервера?

Это нужно в процессе разработки, смысл в том, что модель данных приходится делать 2 раза. 1 раза в CoreData и второй раз в BaaS. Чтоб этот процесс исключить, можно просто один раз сделать модель данных и экспортировать её в BaaS, и так-же поступать со всеми изменениями. В Heroku есть такая штука, называется BuildPack.

возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.
согласен. Мы рассматриваем этот режим запуска сервиса как «Backendless Enterprise». Планируется предоставить возможность загрузки продукта ближе к концу лета.

Вопрос как раз не в том, чтоб разворачивать это у себя на сервере. Суть в том, чтоб быстро это запустить на своей локальной машине только для разработки, а потом одной командой деплоить это на сервер. В Deployd посмотрите, там это основной способ работы. Это очень удобно, если над проектом работает один разработчик. Он работает со своей локальной копией, которая быстро работает без сети через lo интерфейс. А задеплоены все версии, которые уже были выпущены. На них работают тестеры или боевые релизы.

[Funcraft]

Решил попробовать.
1. Зарегался.
2. Создал приложение.
3. Перешёл в Data.
4. Решил добавить таблицу, кликнул «Добавить таблицу». Ввёл название.
5. Появилось две строки (представляющие колонки) update, created.
6. Попробовал изменить имя колонки. По клику на поле появляется календарь о_0. Видимо, из-за того, что тип колонки стоит DATETIME. Суть в том, что ввести словесное имя для такой колонки не представляется возможным. Единственный выход — ставить тип «Строка», менять имя и возвращать тип обратно. При этом, у created невозможно поменять тип.

ЧЯДНТ? Или что я неправильно понял?

[Funcraft]

p.s. Ради теста, решил создать ещё одну таблицу. Так в ней и у update нельзя поменять тип.

[backendless]

Колонки «updated» и «created» являются системными и не подлежат измениям (переименование или изменение значений) разработчиком. Бекендлесс сам изменяет тайм стемп этих колонок когда объект сохраняется (created) или происходит изменение значений колонок. (updated).

[Funcraft]

Почему тогда эти колонки доступны для редактирования?

[backendless]

Редактирование данных для этих колонок невозможно. Возможность редактирования на уровне схемы будет ограничено в окончательном релизе. Спасибо, что указали на этот баг.

[gleb_kudr]

Меня вот что смущает. Везде в подобных сервисах какой-то проприетарный формат хранения данных. Таким образом я у вас захощусь, заведу данные. Вы вдруг накроетесь (ну всякое в жизни бывает).
И что мне после этого делать? Писать бэкенд с нуля?

Почему бы не сделать открытый формат и монетизировать инфраструктуру вокруг него? Таким бы я лично пользовался.

Ну и предложение — запилить бибилиотеку интеграции для линейки mono (monotouch/monodroid). Раз уж мы ведем речь о независимости от платформы, то это очень логичный шаг.

[backendless]

Таким образом я у вас захощусь, заведу данные. Вы вдруг накроетесь (ну всякое в жизни бывает). И что мне после этого делать? Писать бэкенд с нуля?

Вам будет достаточно делать периодический экспорт своих данных.

Почему бы не сделать открытый формат и монетизировать инфраструктуру вокруг него? Таким бы я лично пользовался.

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

Ну и предложение — запилить бибилиотеку интеграции для линейки mono (monotouch/monodroid).

Для любого типа клиента, для которого мы не публикуем нативную библиотеку, вы можете использовать РЕСТ АПИ.

[gleb_kudr]

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

Ну смотрите. Я данные экспортнул. А дальше что мне с ними делать? Приложение у меня умеет общаться только с вашим сервером по проприетарному АПИ. Т.е. мне нужно либо переписывать полностью это общение для использования новой базы, либо писать свою прослойку и самостоятельно реализовывать ваше АПИ поверх какого-либо хранилища данных.

Оба варианта мягко говоря не самые простые.

[backendless]

Оба варианта мягко говоря не самые простые.

Мы (и вы) не одиноки в подобной ситуации. Допустим вы работаете с hibernate, как легко вы можете перейти на другой персистенс фреймворк? Совершенно нелегкая задача. Допустим вы работаете с MySQL и решили перейти на Oracle. Насколько это будет просто? Также непростая задача. Среди BaaS провайдеров нет единого стандарта по АПИ или по формату хранения данных. Возможно ли переписать программу которая работает с Parse и перевести ее на Backendless? Безусловно! Будет ли это просто? Это зависит от сложности программы. Тоже самое будет правдой и в обратную сторону. Здесь чудес никаких быть не может.

[gleb_kudr]

Допустим, я работаю с MySQL. Накрылся один провайдер — залил бекап к его соседу и продолжаю работать дальше. Когда такое станет возможно с облачными платформами — с ними можно будет серьезно иметь дело. Пока же это для всяких игрушечных приложений и легких кейсов, типа организации простой авторизации, без наворачивания функционала.

[s0lar]

Как я понимаю, тут вопрос выбора: хочешь пользоваться или нет! Хочешь пользоваться — принимай правила игры.
Основная идея, как мне кажется — возможность быстро попробовать/протестировать приложение. Если дело пошло, то можно переписать весь бекэнд под себя и экспортировать данные из сервиса. Вуаля!

[Tenkoff]

как-то у вас с кодировками полный ахтунг :(

русские буквы превращаются в феерические вопросительные знаки

[backendless]

Дайте пожалуйста знать где именно? Вызов АПИ или где то в консоли?

[Tenkoff]

[skywatcher]

Полноценный бэкенд это никогда не заменит. И это хорошо.

[Shimizu]

И это хорошо.

Для серверных разработчиков, да, пока хорошо — работа будет. Но, в целом, тренд идёт в эту сторону. Рано или поздно станет плохо.

[skywatcher]

тренд чего? покрыть 3 процента use-case'ов, а потом упереться в технческие ограничения?

[backendless]

Полноценный бэкенд это никогда не заменит.

Что вы вкладываете в понятие «полноценный бэкенд»?

[skywatcher]

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

[backendless]

Как минимум 50 000 разработчиков думают иначе. Что-то подсказывает мне, что количество самых популярных юзкейсов для бэкенда не составляет бесконечное множество и скоро будет покрыто рынком. С какими ограничениями вы столкнулись в своих проектах?

[skywatcher]

Я рад за 50 000 разработчиков. А еще я рад, что меня среди них нет ;-)

[buagaga]

а почему в данной статье нет примеров кода для Flex / Action Script?

[backendless]

Были продемонстрированы самые популярные. Скачайте пожалуста СДК для флекса, там есть примеры для каждого АПИ

[Jeditobe]

Задам нубский вопрос, а сайт на основе вашего БааС можно сделать?

[backendless]

Можно :)

[Indexator]

А все вопросы связанные с хранением и обработкой персональных данных и соблюдением закона о ПД вы тоже сами решаете?

[backendless]

По всем вопросам соблюдения закона мы обращаемся к юристам и следуем их рекомендациям.

[backendless]

/

[yarax]

Я извиняюсь, а есть нужен XHR, как обходится cross origin?

[AndreasCrazyDogVisconti]

Извините пожалуйста, а можно писать кодом? А то мне уже надоел этот конструктор, непонятно ничего. Пока Parse для меня лучше только тем, что там нормальный понятный nodejs, а не визуальное программирование мышкой, как в backendless…