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