Как стать автором
Обновить
3
0

Пользователь

Отправить сообщение
Полноценный бэкенд это никогда не заменит.
Что вы вкладываете в понятие «полноценный бэкенд»?
Чтобы не быть голословным, давайте рассмотрим реальное приложение. Например пример от того же Парса. Если пройти по коду примера, то видно что при минимальном использовании приложения происходят следующие вызовы:
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,000,000 пользователей. Если этот же сценарий сделать более реалистичным, картина совершенно другая. Например, допустим приложение делает 1 АПИ запрос в день (это маловероятно, количество запросов намного выше). Таким образом за месяц будет сделано 30,000,000 запросов. С Парсом это будет стоить: 29,000,000 / 1000 * 0.07 = $2,030. у нас это будет стоить $1000, только за юзеров, то есть в 2 раза дешевле.
Оба варианта мягко говоря не самые простые.
Мы (и вы) не одиноки в подобной ситуации. Допустим вы работаете с hibernate, как легко вы можете перейти на другой персистенс фреймворк? Совершенно нелегкая задача. Допустим вы работаете с MySQL и решили перейти на Oracle. Насколько это будет просто? Также непростая задача. Среди BaaS провайдеров нет единого стандарта по АПИ или по формату хранения данных. Возможно ли переписать программу которая работает с Parse и перевести ее на Backendless? Безусловно! Будет ли это просто? Это зависит от сложности программы. Тоже самое будет правдой и в обратную сторону. Здесь чудес никаких быть не может.
Дайте пожалуйста знать где именно? Вызов АПИ или где то в консоли?
Таким образом я у вас захощусь, заведу данные. Вы вдруг накроетесь (ну всякое в жизни бывает). И что мне после этого делать? Писать бэкенд с нуля?
Вам будет достаточно делать периодический экспорт своих данных.

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

Ну и предложение — запилить бибилиотеку интеграции для линейки mono (monotouch/monodroid).
Для любого типа клиента, для которого мы не публикуем нативную библиотеку, вы можете использовать РЕСТ АПИ.
Спасибо за развернутый комментарий.

авторизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth)
основа для этого уже есть, добавление OpenID и OAuth в планах.

нормальный способ писать логику на сервере
работа над этим уже ведется (к концу июня)

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

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

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

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

возможность локально развернуть сервис, как это сделано в deployd. Позволит писать приложение без интернета. Иногда очень полезно.
согласен. Мы рассматриваем этот режим запуска сервиса как «Backendless Enterprise». Планируется предоставить возможность загрузки продукта ближе к концу лета.
Колонки «updated» и «created» являются системными и не подлежат измениям (переименование или изменение значений) разработчиком. Бекендлесс сам изменяет тайм стемп этих колонок когда объект сохраняется (created) или происходит изменение значений колонок. (updated).
Кстати, поделитесь пожалуйста опытом. Как вы сами решили эту задачу для своего бэкенда?
Всегда пожалуйста. Ждем отзывов, замечаний и пожеланий.
Для авторизированных пользователей тоже есть настройки security системы: через назначение ролей этому пользователю или напрямую указывая, какие права и какие операции данный пользователь может совершать.
Парс намного дороже, у нас АПИ вызовы безлимитно. Кроме-того, проще в использовании (время для старта в разы ниже), поддержка версионности на уровне приложения, фильтрация сообщений, флекс/эйр, видео стриминг… далее по списку в обзоре.

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

По поводу отличий… Иметь возможность выбора хорошая штука, правда? Вообще-то в конце обзора и комментарием ниже все перечислено, не хотелось бы повторяться.
Разработчик приложения имеет возможность запретить любую из АПИ операций используя нашу security систему. Например операция CREATE может быть запрещена для роли NotAuthenticatedUser, таким образом сценарий описанный в вопросе будет невозможен.
Часть логики действительно переходит на сторону клиента. Для определенного типа приложений это нежелательно или неприемлимо. Для этого мы работаем над возможностью добавления своего серверного кода в серверную часть приложения. Поддержка серверного кода будет доступна ориентировочно к концу июня. Stay tuned

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность