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

    Привет Хабр!

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



    (Осторожно: под катом много примеров простого кода. Любителям «велосипедов» читать не рекомендуется. После роста популярности данного сервиса ожидается ликвидация угрозы глобального потепления массовое сокращение депрессий от рутинных задач при написании серверной части.)

    Backendless – платформа бэкенд как сервис (Backend as a Service), которая предоставляет готовую облачную серверную инфраструктуру для всех типов приложений. Это позволяет разработчикам, стартапам и крупным компаниям выигрывать время и деньги, отказавшись от разработки своего сервера, и сфокусироваться на функциональности приложений, их продвижении и пользователях (улучшении UX). АПИ платформы доступны через нативные СДК для следующих клиентских окружений: JavaScript, Android, iOS, Windows Phone, Flex/AIR. Все АПИ также доступны через REST.

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

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


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

    Детализация причин попробовать
    Избегаем необходимости иметь дело с
    • сервером приложения
    • базой данных
    • клиент-серверной библиотекой
    • написанием админки
    • дизайном своего АПИ
    • и хостингом.


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

    Для чего:
    BaaS потенциальный стандарт индустрии для
    • прототипов
    • мобильных приложений
    • кросс-платформенных приложений (можно использовать одну и ту же платформу для всей своей базы пользователей на смартфонах, планшетах или ПК (через браузерные и десктоп приложения)
    • энтерпрайз приложений (и интеграции существующих backoffice систем с новыми мобильными приложениями).

    Для кого:
    Разработчики, стартапы, цифровые агентства и контент провайдеры, системные интеграторы, издатели приложений, энтерпрайз компании.

    Функционал платформы:

    User Management API (управление пользователями) – обеспечивает для приложения регистрацию и логин пользователей, восстановление пароля или апдейты учетной записи кросс-платформенно.

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

    Примеры кода:
    Android
    {
    Backendless.UserService.login(
    
    ”james.bond@mi6.co.uk",
    
            ”i.am.bond",
    
          asyncCallback ); 
    }
    

    iOS
    {
    [backendless.userService login:
    
    @”james.bond@mi6.co.uk"
    
       password:@”i.am.bond"
    
      responder:responder];
    }
    

    JavaScript
    {
    Backendless.UserService.login(
    
    ”james.bond@mi6.co.uk",
    
            ”i.am.bond",
    
            responder );
    }
    

    Data Service API (реляционные данные) – обеспечивает хранение данных пользователей. Приложения могут хранить, обновлять, удалять данные и осуществлять поисковые запросы.

    Пояснение: с сервисом можно работать не имея никаких знаний о базах. Платформа позволяет создавать свои таблицы и связи между ними при помощи АПИ. На клиенте достаточно создать структуру данных, при вызове метода СДК сервер создаст нужные таблицы и свяжет их между собой. Либо это можно сделать с помощью интуитивного пользовательского интерфейса через веб-консоль.

    Примеры кода:
    Android
    {
    Person person = new Person(
    "Bob", 35, "bobby@gmail.com");
    Backendless.Persistence.of( Person ).save( person, asyncCallback );
    }
    

    iOS
    {
    Person *person = [Person new];
    
    person.name = @"Bob";
    
    person.email = @"bobby@gmail.com";
    
    id <IDataStore> dataStore =
    
    [backendless.persistenceService of:   
    
        [Person class]];
    [dataStore save:person responder:resp];
    }
    

    JavaScript
    {
    var person = new Person(
        "Bob", 35, "bobby@gmail.com");
    Backendless.Persistence.of( Person ).save( person, responder );
    }
    

    Publish/Subscribe Messaging API (сообщения) – клиентские приложения могут обмениваться сообщениями в режиме реального времени путем создания Издателей (Publishers) и Подписчиков (Subscribers).

    Пояснение: Сообщением может быть любые произвольные (дискретные) данные. Эта функция полезна при разработке игр, чатов и приложений требующий транслирование данных (data broadcast) или p2p доставку. Отсылка push уведомлений и in-app сообщения мобильным пользователям.

    Примеры применения: чат, синхронизация клиентских приложений, уведомление пользователей о чем либо.

    Примеры кода:
    Android
    {
    Backendless.Messaging
    
        .subscribe( ”myChannel",
    
        methodCallback,
        subscriptionCallback );
    }
    

    iOS
    {
    subscription = [backendless.messagingService                      
    
    subscribe:@"myChannel"
    
        subscriptionResponder:responder
    subscriptionOptions:subscriptionOptions];
    }
    

    JavaScript
    {
    Backendless.Messaging
    
        .subscribe( "private_channel",
    
        methodResponder,
        subscriptionResponder );
    }
    

    Push Notifications API (уведомления) – это подраздел сообщений, но с нативной интеграцией доставки сообщения мобильному устройству как push уведомления. Поддерживаются для iOS, Android и Windows Phone.

    Примеры кода:
    Android
    {
    Backendless.Messaging
    
        .publish( "Hello!",
    
            new DeliveryOptions(
    
                PushBroadcastMask
    
                    .ANDROID ));
    }
    

    iOS
    {
    PublishOptions *p = [PublishOptions new];
    
    [p addHeader:@"Name" value:@"Anonymous"];
    
    
    MessageStatus *res =  [backendless.messagingService
    
       publish:@"myChannel"
    
       message:@"Hello!" publishOptions:p
    
       deliveryOptions:[DeliveryOptions  
    
           deliveryOptionsForNotification:PUSHONLY]];
    }
    

    JavaScript
    {
    Backendless.Messaging
    
        .publish( "Hello!",
    
            new DeliveryOptions(
    
                PushBroadcastMask
    
                    .ANDROID ));
    }
    

    Geolocation API (геолокация) – приложения могут регистрировать географические координаты (гео точки) с дополнительными метаданными на сервере и впоследствии осуществлять поисковые запросы для других точек по метаданным в пределах заданного радиуса или квадрата.

    Возможные примеры применения в повседневной жизни:
    • родители — сервис автоматической привязки фото тех мест где находятся их дети.
    • службы доставки и курьеры — фотографии объектов адресатов;
    • автомобилисты — состояние дорог и точной погоды в радиусе;
    • туристы — достопримечательности в округе;
    • авто-путешественники — список ближайших ресторанов/отелей с меню и ценами, свободными местами;
    • указание расположения друзей, если они находятся поблизости;
    • пользователь делает посты с указанием категории — на пр. “рестораны” (и добавляет фото интерьера ресторана) или романтическое место (добавляет фото какого-то пейзажного места). после этого любой другой пользователь может отфильтровать просмотр только романтических мест вокруг него;.
    • приложение, которое будет знать местоположение пользователя, с заданным радиусом. Другие репортируют какую то ситуацию или событие, и если в данный момент эта ситуация попадает в заданный радиус, пользователь получает уведомление (информация о пробках или гаишниках на дороге, происшествиях).

    Примеры кода:
    Android
    {
    Backendless.Geo.getPoints(
    
        new BackendlessGeoQuery(
    
            "city", ”Kiev" ),
        asyncCallback );
    }
    

    iOS
    {
    BackendlessGeoQuery *query = [BackendlessGeoQuery query];
    
    [query metadata:[NSDictionary
    
        DictionaryWithObjectsAndKeys:
    
        @"Moscow", @"city", nil]];
    
    
    [backendless.geoService getPoints:query  
                                                
                     responder:responder];
    }
    

    JavaScript
    {
    Backendless.Geo.getPoints(
    
        new BackendlessGeoQuery(
    
            "city", ”Dallas" ),
        responder );
    }
    

    Media Services API (медиа потоки) – набор сервисов обеспечивающих “проигрывание по запросу” и живое потоковое видео и аудио. Приложения могут публиковать потоки с видеокамеры и микрофона для записи или живого вещания. Записанное медиа (видео или аудио) и живые стримы можно воспроизводить на других клиентах.

    Пояснение: Медиа сервис позволяет стримать видео или аудио с клиентского приложения на сервер и воспроизводить этот поток на других устройствах. Так же можно воспроизводить медиа контент загруженый с помощью файл сервиса.

    Примеры применения: видео-конференция, видео-чат, живая видео-трансляция одновременно с или на все устройства (с телефона, планшета, камеры ПК), запись видео или аудио сразу на сервер, живая аудио-трансляция (радио, музыка)

    Примеры кода:
    iOS
    {
    MediaPublishOptions *options =    [MediapublishOptions
    
        recordStream:self.preview];
    
    [backendless.mediaService
    
        publishStream:@”myVideoChannel"
    
        tube:@”Funny Dance"
        options:options responder:resp];
    }
    

    File Service API (хранилище контента) – поддерживает загрузку, общий доступ и скачивание файлов или блоков данных. Файлы/данные могут связываться с постоянными записями данных из сервиса реляционных данных, сообщениями и гео-точками.

    Пояснение: Сервис по управлению файлами дает возможность заливать и получать доступ к файлам через консоль или клиентские СДК.

    Примеры применения: хранение и управление контентом, стриминг залитого видео, обновление контента без необходимости обновлять приложение.

    Примеры кода:
    Android
    {
    Backendless.Files.upload(
        file, path, asyncCallback );
    }
    

    iOS
    {
    [backendless.fileService upload:path
        content:content
        responder:responder];
    }
    

    JavaScript
    {
    Backendless.Files.upload(
    
            fileList,
            ”myFolder"),
        responder );
    }
    

    Чем данная платформа лучше других?

    Версионность — с общими данными/таблицами между версиями – создав приложение вы можете сделать официальный релиз, а в это время работать над другой версией этого же приложения.

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

    Фильтрация сообщений — работает фильтрация сообщений по саб-топикам, а так же можно задать фильтр в sql виде, так называемый селектор.

    Поддерживаются flex/air клиенты — в наличии СДК для ActionScript. С помощью флэша приложение будет выглядеть на любом устройстве одинаково, и без танцев с бубном.

    Коробочное решение — можно получить свой in-house Backendless из коробки. Крупные энтерпрайз клиенты могут развернуть платформу на своих собственных серверах только для себя.

    Гибкое ценообразование и «жирный» бесплатный план — в фримиум входят: АПИ вызовы безлимитно, 2 GB дискового пространства, 200,000 publish/subscribe messages, 200,000 push notifications. Платить если и придется, то только за то, что будет непосредственно использоваться. Подробнее посмотреть и посчитать можно здесь с помощью удобного калькулятора. Кроме того, пока платформа в бете, любые лимиты – формальная условность.

    АПИ и вебконсоль — тщательно зашлифованы под разработчиков, потому что простоте и удобству уделяется максимум внимания.

    Автомасштабируемость — платформа размещена на инфраструктуре Амазона и автоматически масштабируется при возникающих нагрузках: по месту и по используемой памяти. В случае превышения критического лимита при обработке запросов запускаются дополнительные виртуальные машины.

    Как начать: регистрируемся или заходим сразу в веб-консоль разработчика через ФБ авторизацию, качаем СДК с примерами, прописываем ключи для каждого СДК, пишем вызов к АПИ и все: ваш облачный бэкенд в вашем распоряжении.

    В техподдержку можно присылать вопросы на русском. Офисы компании расположены в Штатах и Украине.

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

    Вам знакома концепция «бэкенд-как-сервис»?

    Backendless
    30,00
    Компания
    Поделиться публикацией

    Комментарии 56

      0
      А логику оставить на клиентской части? Не доверяю я таким вещам. Однако есть приложения, которым этих возможностей за глаза хватит…
        0
        Многие BaaS платформы предоставляют возможность добавить серверный код. Так что на клиент логика не выносится.
          +1
          Часть логики действительно переходит на сторону клиента. Для определенного типа приложений это нежелательно или неприемлимо. Для этого мы работаем над возможностью добавления своего серверного кода в серверную часть приложения. Поддержка серверного кода будет доступна ориентировочно к концу июня. Stay tuned
            0
            А вот это значимое и приятное уточнение! Спасибо!
              0
              Всегда пожалуйста. Ждем отзывов, замечаний и пожеланий.
          +3
          Круто! А что будет, если пользователь откроет консоль в хроме и насоздает миллион левых записей в базе? Есть какая-то защита от этого?
            0
            Разработчик приложения имеет возможность запретить любую из АПИ операций используя нашу security систему. Например операция CREATE может быть запрещена для роли NotAuthenticatedUser, таким образом сценарий описанный в вопросе будет невозможен.
              +1
              Для неавторизованных понятно. А как насчет обычного пользователя, у которого есть возможность, например, написать комментарий? Сможет ли он провернуть описанную мной махинацию?
                0
                Может, запросто!
                  +3
                  Кстати, поделитесь пожалуйста опытом. Как вы сами решили эту задачу для своего бэкенда?
                    0
                    Может, оповещение админа и блокировка этой функции для пользователя, если количество запросов от него превышает разумные значения. Ну и возможность изменения этих значений.
                  0
                  Для авторизированных пользователей тоже есть настройки security системы: через назначение ролей этому пользователю или напрямую указывая, какие права и какие операции данный пользователь может совершать.
              0
              Backendless API documentation is currently available only for iOS

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

                По поводу отличий… Иметь возможность выбора хорошая штука, правда? Вообще-то в конце обзора и комментарием ниже все перечислено, не хотелось бы повторяться.
                +2
                Уже подсел на Parse.com
                  0
                  Парс намного дороже, у нас АПИ вызовы безлимитно. Кроме-того, проще в использовании (время для старта в разы ниже), поддержка версионности на уровне приложения, фильтрация сообщений, флекс/эйр, видео стриминг… далее по списку в обзоре.

                  Какие фичи вам бы хотелось иметь, каких еще нет у Парса?
                    0
                    Что-то я не совсем понял насчет того, что Parse «намного дороже».
                    Если у меня 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 раза дешевле.
                        +1
                        Для такого сценария у Parse покупается Pro-аккаунт за $199 c 15млн запросов и и для оставшихся 15млн платится 15000000 / 1000 * 0.05 = $750, что в сумме дает $949.
                        Вообще, платить за пользователей — это дикость, по-моему…
                        Цены на пуши, опять же, у вас в 10 раз выше, чем в бесплатном тарифе Parse (в Pro — выходит более, чем в 10 раз выше).
                        Я не ради холивара — просто утверждать, что Parse «намного дороже» не очень корректно в данном случае ;)
                          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…
                            0
                            Убедили, спасибо.
                      0
                      Я же написал «подсел». Это значит, что куча кода уже ориентировано на Parse. Можно переехать без больших проблем, но пока незачем.
                    +1
                    Хорошо конечно, но то чего я не нашел ни в одном существующем сервисе:
                    — автоизация и регистрация с помощью сторонних сервисов ( OpenID, OAuth), у тех что есть ограничего все Facebook и Twitter. Для русского сегмента не хватает как минимум вконтакта. Жду когда в http://deployd.com появится поддержка passport фреймворка. Умел бы — сам допилил.
                    — нормальный способ писать логику на сервере (побольше возможностей, дергать сторонние сервисы например, писать свои модули).
                    — поддержка NSIncrementalStore и кэширования в CoreData уже в самом SDK (это не сложно, но писать для того-же parse.com нет охоты, если и сделаю, то для deployd)
                    — поддержка механизма планируемых задач, типа cron, Например для отправки пользователям уведомления о чем-либо каждый день или сбора данных или еще чего-либо. В том-же Parse это реализовано через CallBack, то-есть нужен кто-то кто бы эти функции периодически дергал
                    — экспорт и мержинг при изменении CoreData модели в BaaS.

                    Вот этого не хватает ни в одном существующем BaaS, а практически для каждого приложения это нужно, из тех, что я делаю.
                      0
                      А чуть не забыл, еще поддержка 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 невозможно поменять тип.

                          ЧЯДНТ? Или что я неправильно понял?
                            0
                            p.s. Ради теста, решил создать ещё одну таблицу. Так в ней и у update нельзя поменять тип.
                              0
                              Колонки «updated» и «created» являются системными и не подлежат измениям (переименование или изменение значений) разработчиком. Бекендлесс сам изменяет тайм стемп этих колонок когда объект сохраняется (created) или происходит изменение значений колонок. (updated).
                                0
                                Почему тогда эти колонки доступны для редактирования?
                                  0
                                  Редактирование данных для этих колонок невозможно. Возможность редактирования на уровне схемы будет ограничено в окончательном релизе. Спасибо, что указали на этот баг.
                            0
                            Меня вот что смущает. Везде в подобных сервисах какой-то проприетарный формат хранения данных. Таким образом я у вас захощусь, заведу данные. Вы вдруг накроетесь (ну всякое в жизни бывает).
                            И что мне после этого делать? Писать бэкенд с нуля?

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

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

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

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

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

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

                              русские буквы превращаются в феерические вопросительные знаки
                                0
                                Дайте пожалуйста знать где именно? Вызов АПИ или где то в консоли?
                              0
                              Полноценный бэкенд это никогда не заменит. И это хорошо.
                                0
                                И это хорошо.


                                Для серверных разработчиков, да, пока хорошо — работа будет. Но, в целом, тренд идёт в эту сторону. Рано или поздно станет плохо.
                                  0
                                  тренд чего? покрыть 3 процента use-case'ов, а потом упереться в технческие ограничения?
                                  0
                                  Полноценный бэкенд это никогда не заменит.
                                  Что вы вкладываете в понятие «полноценный бэкенд»?
                                    0
                                    Именно то и вкладываю. Используя коробочное решение упираешься в ограничения этого черного ящика(коробочного решения). А дальше хоть вешайся.
                                      0
                                      Как минимум 50 000 разработчиков думают иначе. Что-то подсказывает мне, что количество самых популярных юзкейсов для бэкенда не составляет бесконечное множество и скоро будет покрыто рынком. С какими ограничениями вы столкнулись в своих проектах?
                                        0
                                        Я рад за 50 000 разработчиков. А еще я рад, что меня среди них нет ;-)
                                  0
                                  а почему в данной статье нет примеров кода для Flex / Action Script?
                                    0
                                    Были продемонстрированы самые популярные. Скачайте пожалуста СДК для флекса, там есть примеры для каждого АПИ
                                    0
                                    Задам нубский вопрос, а сайт на основе вашего БааС можно сделать?
                                    0
                                    А все вопросы связанные с хранением и обработкой персональных данных и соблюдением закона о ПД вы тоже сами решаете?
                                      0
                                      По всем вопросам соблюдения закона мы обращаемся к юристам и следуем их рекомендациям.
                                      0
                                      /
                                        0
                                        Я извиняюсь, а есть нужен XHR, как обходится cross origin?

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое