Имам нужда от облачна база данни: Firebase или CloudKit?

Често срещано погрешно схващане, че Firebase и CloudKit са доста взаимозаменяеми. Въпреки че и двете са сървърни решения за съхранение, трябва да вземете внимателно техните функции, преди да решите да използвате едно или друго

Както Firebase, така и CloudKit са част от по-големите платформи, които предоставят много функции - в тази статия ще се съсредоточа върху модула на базата данни на всеки, особено техните аспекти в реално време.

На кутията

Firebase казва:

Базата данни за реално време на Firebase е базирана в облак база данни NoSQL, която ви позволява да съхранявате и синхронизирате данни между вашите потребители в реално време.

CloudKit обещава:

Съхранявайте данните на приложението си в iCloud и поддържайте всичко актуално в приложенията и в мрежата с CloudKit JS

Звучи ли подобно? Вземете чаша и прочетете на ...

В кутията

Стил на базата данни

Най-лесно е да си представите база данни на Firebase, сякаш това е хранилище на Subversion: всичко живее под един корен и оттам можете да правите каквото си поискате. Това е ясно веднага, когато преглеждате базата данни от конзолата Firebase:

JSON!

Недостатъкът на това е, че ще трябва ръчно да управлявате препратки към други възли в дървото (ако е необходимо).

CloudKit, от друга страна, е по-скоро традиционна база данни в релационен стил, където обектите се отнасят към децата по идентификатор:

Освен ако, разбира се, не искате масив, в този случай Apple препоръчва да използвате задни указатели

CloudKit има явно предимство пред Firebase тук, когато става дума за много към много или подобни взаимоотношения. Въпреки това, по време на писането, CloudKit все още е в начална фаза и все още не е възможно клиентът да поиска няколко нива на обектната графика. За да поискате всички тези обекти в нашия пример от база данни на Firebase, можете просто да ВЗЕМЕТЕ възела, който искате и всички деца ще се върнат с него точно както бихте очаквали от тях - като буквална структура на JSON:

Инсталирайте jq, това ще промени живота ви, обещавам.

Когато се опитвате да поискате една и съща обектна графика от база данни в CloudKit (ако не знаете референтните идентификационни номера на всяко от децата), ще трябва да направите заявка за всяко ниво. За да получите всички примерни данни по-горе от базата данни на CloudKit, трябва да:

  • Вземете обекта Потребител, използвайки неговия идентификационен номер
  • Създайте масив от идентификатори, които сочат към детайли и частни обекти и ги заявете. Ще получите отговори в масив от обекти, които са в същия ред като идентификационните номера в заявката
  • Вземете идентификационния номер на информацията от модела за отговор на детайли и направете още една заявка

Докато работя с CloudKit, установих, че това е доста смущаващо и впоследствие започнах да структурирам данните си или да имат по-малко деца. Друго нещо, което трябва да се отбележи на този етап, е, че данните в SDK на CloudKit iOS се увиват като CKObjects вместо необработен JSON, така че не можете да използвате JSONDecoder за сериализиране на собствените си модели.

Резюме: CloudKit има ясното предимство, че можете лесно да насочвате референции, където пожелаете, но трябва да направите нова HTTP заявка за всяко ниво в обектната графика, се чувствате излишни, увеличава точките на отказ и поставя ненужен стрес на клиента.

Realtime-ност

Една голяма точка за продажба и на двете услуги е тяхната проактивност, когато става въпрос за синхронизиране на съдържанието между множество клиенти. И отново двамата подхождат към тази задача в много различен стил.

Когато се абонирате за възел в базата данни на Firebase, SDK установява уебсакет, чрез който всички промени, които се случват на или под възела, се предават на клиента. Това е.

Вкусна магьосница на Websocket

Ако който и да е долен възел е актуализиран, делтата ще достигне до вашия клиент и обратният разговор ще се задейства от SDK, като ви предоставя незабавен достъп до наскоро актуализираната JSON структура, за която сте се абонирали. Конзолата Firebase също отразява всички промени в реално време:

Уебсакетите ме правят щастлива.

CloudKit също има API, който позволява да се абонирате за заявка / предикат и да получавате обратни повиквания при промяна на съвпадащи обекти. Ето стъпките, които трябва да се предприемат за iOS клиент, използвайки родния CloudKit SDK:

В началото е малко страшно ...

Не се притеснявайте, ще ви преведа през това:

  1. Клиентът записва обект на абонамент в базата данни, който описва промените, за които иска да бъде уведомен. Сървърът отговаря с поставен обект на абонамент. Трябва да запазите неговия идентификатор, тъй като ще ви е необходим по-късно.
  2. Когато обект се промени, CloudKit уведомява APNS с идентификатора на абонамента
  3. APNS изпраща push известие до клиента
  4. Клиентът трябва да съответства на идентификатора на входящия абонамент с записания в стъпка 2, за да реши какво да прави. След това клиентът трябва да донесе промените, настъпили в отдалечената база данни

Това е доста заобикалящ процес и има много възможни точки на провал. Във видеоклип от CloudDit от WWDC16 водещият заявява:

... не бива да мислите за push като начин да кажете на приложенията си какво се е променило, защото ако са изпратени 5 тласкания, но сте пропуснали 4 от тях, ще пропуснете 4 от тези, които има.

След това презентаторът продължава да обсъжда как е възможно да се поиска само промененото, без да знае идентификаторите. Всъщност видеото говори много за случаите на известяване чрез натискане, тъй като не е проста задача.

Друго важно нещо, което трябва да се отбележи за CloudKit, са актуализациите на детски обекти, които не задействат родителски абонаменти. Например, ако се абонирате за Потребител в CloudKit, когато детайлите или информационните обекти са актуализирани, няма да бъдете известявани. Това е наистина неочаквано и добавя слой затруднение към вашето развитие, което според мен трябва да бъде абстрахирано от SDK. В нашия проект трябваше да работим с много нива на данни, но установихме, че известията са ненадеждни (вероятно защото ни трябваха толкова много абонаменти), така че в крайна сметка кодирахме нашата детска обектна верига като байтове JSON и я съхраняваме като балон данни ... не е идеално, но това беше единственият начин да намалим натоварването на клиента.

Резюме: Установих, че Firebase е много по-интуитивен и много по-надежден от CloudKit за получаване на актуализации на данни в реално време.

Четене и писане

Отново Firebase се държи точно както се очаква. Можете да PUT, PATCH (макар и не е истинска лепенка) POST и ИЗТРИВАНЕ данни в съдържанието на сърцето си. За да създам конзолните данни, променящи GIF по-горе, просто използвах този скрипт:

#! / Хамбар / Баш
  
USER_ROOT = "https://playground-df93e.firebaseio.com/users/9FFC9BD7-D00F-4214-ACC7-A5D4837D4A8E"

извиване -X PATCH \
    -d "{\" lastLogin \ ": \" $ (дата) \ "}" \
    "$ USER_ROOT / private.json"

сън 5

извиване -X PATCH \
    -d '{"резултат": 125, "delta": 5}' \
    "$ USER_ROOT / подробности / info.json"

Методът GET може да се използва за извличане на данни през HTTP. По подразбиране Firebase ще спечели най-новото записване, но можете да определите свой собствен обработващ резолюция. И, ето, SDK за Firebase гласи:

Ако клиент загуби мрежовата си връзка, приложението ви ще продължи да функционира правилно.

Firebase поддържа локално копие на данните, които използвате за подобряване на отзивчивостта при бавни мрежови условия. Трябва да се отбележи, че базата данни в реално време има максимална дълбочина от 32 възли, но това би трябвало да е повече от достатъчно за повечето приложения ...

Обществената база данни на CloudKit е обществена само за всички потребители на приложението, така че не е проста задача да се създаде означение за тестване чрез curl. Когато настройвате базата данни, трябва да посочите типа на всяко поле, но разбира се, те не се въвеждат силно при четене / писане от SDK, така че единственото предимство пред Firebase е, че сървърът ще отхвърля неочаквани типове.

Използвахме CloudKit широко в приложение за iOS, интензивно в реално време и установихме, че когато има много потребители, които трябва да актуализират обект, вероятно ще се сблъскате с конфликти при писане. За щастие, CloudKit предоставя правила за запазване (по подразбиране е да се прекрати писането, ако записът на сървъра предстои), за да се определи как да се справи с разрешаването на конфликта. Разочароващо, установихме, че тези правила не действат както се очаква в някои случаи. Добрата новина е, че поискахме поддръжка на ниво код от Apple, каза, че е в процес на коригиране.

Грешки по време на отстраняване на грешки в нашето приложение в реално време в CloudKit

Както се вижда от горния екран, CloudKit е безмилостен, когато става въпрос за ограничаване на скоростта. Проста грешка, която базата данни ви приписва, може да коства вашата операция да бъде отхвърлена за следващите 30 секунди!

CloudKit също има объркващо име на правила за изтриване, така че можете да изберете да каскадирате графиката на обекта, когато изтриете родител, ако това е необходимо. Също така, когато работите с файлове, CloudKit има смартфоните да съхранява само едно копие и да го изтрива, когато няма повече препратки, насочени към него.

Резюме: Firebase е готова да излезе извън кутията и лесно може да бъде разбрана от всеки, но CloudKit обещава по-здрава архитектура (независимо дали предоставя или не е друг въпрос).

заверка

Firebase позволява да се задават специфични правила за достъп за всеки възел или изобщо да няма такива. Удостоверяването на клиента може да се извърши зад кулисите, така че потребителят да не знае, че използвате Firebase.

Пример само!

Моделът за удостоверяване на CloudKit работи наистина добре на устройства с iOS - ако потребителят е вписан в iCloud акаунт в своите системни настройки, добре е да отидете. Ако обаче работите с други платформи, потребителят трябва да бъде пренасочен към страница за вход в iCloud: това е класическият подход на OAuth. CloudKit също така предварително дефинира частна, обществена и споделена база данни, за да помогне за определянето на обхвата, до които вашите потребители могат да имат достъп. Правилата могат да се настройват на таблото за управление:

CloudKit има много раздели.

Резюме: Firebase може да бъде незабавно достъпен без удостоверяване, но също така предоставя гъвкавост за определяне на вашите собствени правила. CloudKit вероятно е по-сигурен и може да осигури безпроблемно изживяване и на вашите потребители, но само ако те използват iOS.

преносимост

Както видяхме по-рано, прости заявки могат да се използват за взаимодействие с данни от Firebase. Има и много официални, много лесни за използване SDK, които избирате - по-специално JavaScript, iOS и Android. Интересът ми обикновено се крие в аспекта в реално време и за това всички те работят почти по един и същи начин:

var firebase = ... // Настройте го
var database = firebase.database ();
database.ref ("потребители"). on ('стойност ", функция (моментна снимка) {
    отпечатате (snapshot.value);
});

След като научите как да го направите на един език, можете да го направите на всеки език.

CloudKit има вграден SDK, който се доставя с Xcode, както и официален JavaScript SDK и RESTful API. Абонаментите също работят в JavaScript SDK, но те са малко по-кръгли, отколкото в Firebase:

var querySubscription = {
    subscriptionType: 'заявка',
    firesOn: ['създаване', 'актуализация', 'изтриване'],
    заявка: {recordType: 'Потребител', filterBy: ...} // Филтрите са страшни
};

publicDB.saveSubscriptions (querySubscription) .then (функция (отговор) {
    ако (response.hasErrors) {
        хвърлят response.errors [0];
    } else {
        // Успех
    }
});

container.registerForNotifications ();
container.addNotificationListener (функция (известие) {
    // Направете нещо с `известие`
    self.fetchRecords ();
});

Създаването на абонамент е подобно на iOS, но както се подразбира по-рано в тази статия, обработката на обратни обаждания се извършва чрез стандартното приложение (_: UIApplication, didReceiveRemoteNotification :) (или това е колега за известяване на фона, тъй като CloudKit поддържа събуждането на приложението ви за получаване на данни) ,

Резюме: И двете решения са преносими. Интеграцията на Firebase е бърза и еднаква в различните платформи. Докато CloudKit има вграден SDK за iOS, ще ви отнеме известно време, за да го стартирате на друга платформа.

Отстраняване на грешки

Както видяхме по-рано, конзолата Firebase показва актуализацията на вашата база данни в реално време и ви позволява да редактирате стойности директно. Можете също да изключите удостоверяването, за да четете и записвате лесно с помощта на къдряне, което прави развитието много по-опростен.

Тази промяна няма да бъде отразена в други възли, разбира се

Таблото за управление на CloudKit има много повече функции от конзолата Firebase. Въпреки че можете да редактирате стойности, данните не се актуализират в реално време, така че трябва непрекъснато да извличате обекти, за да видите промените, направени от клиентите. И ще ви е трудно да напишете скрипт за предварително попълване на данни, които могат да бъдат използвани по време на разработка. Претърпяхме и срив в самата рамка на CloudKit, който при докладване екипът на Apple Bug Report отпадна.

Добавянето на данни в CloudKit е по-ангажирано, но ви дава сигурност. Този GIF също не показва процеса на попълване на препратката, тъй като се притесних, че размерът на GIF ще бъде твърде голям

Резюме: Отново Firebase се развива по-бързо от CloudKit. Ако се притеснявате, че грешният тип ще бъде записан в поле, CloudKit е пътят към това (макар че освен ако не отваряте API за обществото, не мога да видя защо моделите ви вече не са въведени силно ...)

цена

Когато ударите 85% от разпределения си свободен капацитет на Firebase (ако паметта ми ме обслужва правилно), ще получите имейл, напомнящ ви да се абонирате за план за надграждане. Има план на стойност 25 долара на месец, който ще ви донесе щедро надграждане, но ако това не е достатъчно и планът Pay As Go Go:

Таблицата продължава да говори за някои други отлични функции, които не са в обхвата на тази статия.

Данните, съхранявани в частния обхват на базата данни на вашия CloudKit, се отчитат до ограниченията на iCloud на потребителя, така че няма да е необходимо да плащате за това хранилище (въпреки че трябва да имате предвид, че на потребителя може да няма останало много място). Като цяло CloudKit се рекламира като безплатен, като използва плъзгача за изчисляване на стойността, който всъщност никога не актуализира етикета „Обща цена: 0 долара“.

Плъзгачът е толкова възхитителен за игра, че ви отвлича от данните, които сте там, за да гледате.

Има обаче много важен фин шрифт. Тук ще ви цитирам хубаво и голямо:

Ограниченията се изчисляват и се основават на средното използване за общия брой активни потребители на месец. Потребителите трябва да имат активна употреба на контейнери през последните 16 месеца. Ако акаунтът ви надвишава свободните лимити за обществено съхранение, трансфер на данни или искания за секунда, може да се наложат такси за натрупване. Приложението ви няма да получи допълнителни безплатни квоти чрез използване на множество контейнери. Приложимите такси се изчисляват месечно в щатски долари.

Таксите за натрупване са, както следва:

Така че приблизително всеки 100 000 потребители могат да отправят 10 заявки всяка секунда (вижте GIF по-горе), в противен случай плащате 100 долара за всеки 10 заявки над този лимит.

Не съм сигурен дали CloudKit ще ви съобщава предварително за тези ограничения, тъй като никога не съм ги достигнал, но потенциални 100 долара за всеки 10 заявки е добро нещо, което трябва да държите зад гърба на ума си. Също така имайте предвид, че контейнерите от CloudKit не могат да бъдат изтрити, така че няма да можете да „изключите“ CloudKit, ако цената внезапно изчезне.

Резюме: И двете платформи имат безплатни нива, което улеснява започването и дори изграждането на малко продукти срещу. Изглежда Firebase е по-открито прозрачна за ценовата си структура, докато CloudKit изглежда се преструва да ви предостави услугата безплатно и след това ще ви санкционира по-късно.

Присъдата

И двете решения предоставят облачни решения за бази данни, но по много различни начини. Надяваме се, че тази статия ви помага да вземете информирано решение при избора кои да използвате. Както видяхме, Firebase винаги изглежда да работи интуитивно и открито. CloudKit носи повече функции и здрава архитектура на масата, но в някои случаи се опитва да ви засади.

Лично аз винаги бих избрал Firebase за доказателства за концепция, бързи компилации, IoT устройства или нещо, което се нуждае от истинско споделяне на данни в реално време. Избрах CloudKit само ако знаех, че приложението е само iOS и синхронизирането на данни не е необходимо да се случи моментално.