Най-добри практики за разработване на база данни в реално време на Firebase

News Rush използва Firebase вече 4 месеца и въпреки че има неща, които бихме искали да видим подобрени (можете ли да посочите „перфектен продукт?“), Това беше ценно допълнение към нашия стек за нашите изисквания за синхронизиране на мобилни данни.

По пътя научихме някои уроци за това как най-добре да използваме платформата, за да отговорим на нуждите си. Firebase е ориентирана към документи / NoSQL база данни и по този начин споделя много от характеристиките на тези платформи, но също така има някои свои уникални черти, които трябва да научите. Ето бърз мозъчен разрез от това, което открихме по пътя.

RTFM!

SDK документацията обикновено е ужасна, така че много от нас са склонни да се стремят към високите точки и да се връщат към нея по-късно (или никога).

Тук важи точно обратното. Ръководствата и образците са лесни за следване, а Справочните документи са подробни и измамно кратки. Почти всеки път, когато екипът ни имаше въпрос или проблем, ние намирахме решението в нещо, което ни липсваше в документите. В крайна сметка седнахме и прочетохме всяка дума направо, и тя беше добре изхарчена 3 часа.

Има и блог, който е съкровищница за намиране на решения на проблеми от реалния свят. Ето няколко от публикациите, които намерихме най-критични в News Rush:

  • Групова сигурност в базата данни на Firebase
  • Заявки, част 1: Общи SQL заявки, преобразувани за Firebase
  • Най-добри практики: масиви в Firebase

Следствие: „Без схема” не означава без мозък!

Често срещано погрешно схващане, че ориентираните към документи бази данни съставят предварително планиране за това как данните ще бъдат структурирани по-малко важни. Това е мит. Ако не друго, ние открихме обратното: те изискват повече.

Няма нищо необичайно в това, че доброто планиране може да ви помогне да изтръгнете максимална производителност от всеки софтуерен компонент. Но в базата данни на SQL обикновено е лесно да се поправят грешки в планирането или чрез просто присъединяване към повече таблици, извършване на под-заявки или извършване на групови актуализации на данни. Тъй като Firebase няма тези понятия, отделете време да седнете и реално моделирате вашите данни и модели за достъп преди време. Ще се радваш, че го направи.

И RTFM!

Поддръжката е объркваща

Има редица възможности за поддръжка, но опитът да се използва грешен в определена ситуация може да бъде разочароващ. Нашите преживявания са:

  • Отслабване: Самопомощта, ориентирана към общността и мозъчната атака, не са подходящи за други места. Не е подходящ за „нещо е надолу.“
  • Формуляр за поддръжка: Официалното място за поддръжка. Докладвайте „нещо е долу“ тук. Искания за функции, които вероятно ще получат консервиран отговор „ще го разгледаме, но няма обещания“.
  • Google Групи: Активно участие на основния екип с обичайните предупреждения относно времето на изпълнение в групово ориентираните пощенски системи. Най-доброто място за високо технически дискусии относно вътрешните приложения и „странните“ проблеми.
  • StackOverflow: Бавни / непредсказуеми времена на реакция, но най-доброто място за резервни справочни материали. Ако сте чели въпроси и отговори в StackOverflow, знаете типа въпрос, който е най-добре да публикувате и там.

Отговорите и простите изтегляния са „евтини“

В Firebase „ref“ е като указател на данни. Инстинктивно е да искате да кеширате или управлявате по друг начин, но в настоящите библиотеки на Firebase клиент никога не трябва да правите това. Те наистина са просто обвивки около препратките към URL обекти на данни, а обратните извиквания на събития, до които предоставят достъп, могат да имат само един слушател наведнъж. Ако имате нужда от препратка към обект от две различни места, вземете два рефлекса към него. Това не струва повече за това.

Подобно правило важи за извличането на данни. Тези, идващи от SQL бази данни, са свикнали да се опитват да извлекат по-големи обекти в възможно най-малко заявки, за да се елиминира времето за обиколка и запитването отгоре. Когато изравнявате структури от данни, е изкушаващо да копирате „обобщените“ данни на няколко места, за да може едно извличане да получи всичко необходимо.

В Firebase това е почти изцяло грешно решение. За едно нещо, прости извличания на базата на ключ / ref са силно оптимизирани и Firebase предлага масивни хоризонтални мащаби за тях. В нашето тестване за ефективност в News Rush открихме също, че Firebase се справя много по-добре с повече, по-малки обекти. Дори премахването на няколко ненужни полета може да осигури измеримо увеличение на производителността.

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

Избягвайте масиви

Документацията на Firebase вече обхваща тази тема. Всичко е правилно. Избягвайте ги.

Без дати

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

Един размер не отговаря на всички

Тогава изглеждаше толкова добра идея ...

Използвайте силните страни на Firebase. Не се опитвайте да го накарате да върши всяка ваша работа. Ето някои неща, които Firebase не е:

  • Търсачка. Той има няколко основни операции като съвпадение на префикс, но това е всичко. Използвайте ELK, Algolia и др., Ако се нуждаете от пълно търсене.
  • Стека на API. Облачните функции за Firebase изглеждат много обещаващи, но все още са в бета версия. Ако приложението ви е нещо повече от списък със задачи, планирайте как ще извършите изпълнението на код от страна на сървъра / надежден код.
  • Двигател за отчитане. Все още може да искате да използвате релационна база данни, когато трябва да режете / зарязвате / филтрирате / мутирате / мюнгирате / и т.н. вашите данни.
  • Самостоятелно хоствано или напълно използваемо офлайн. Офлайн функционалността се предоставя чрез синхронизиране / постоянство, но облакът Firebase трябва да бъде включен в началото.

Задаване спрямо актуализация

Има голяма разлика между операциите SET и UPDATE. Той влияе върху това, което се случва, ако ключ все още не съществува, особено ключовете вътре в сложни обекти. Обърнете внимание!

FirebaseUI е страхотно!

О, трябва да спомена, има много придружаващи проекти на FirebaseUI за много платформи. Използвай ги. Те са изключително полезни за неща като настройка на изглед на таблица за показване на списък от обекти в колекция Firebase.

Тази библиотека предоставя класове FUICollectionViewDataSource и FUITableViewDataSource (и техните еквиваленти в Android), които правят стартирането на мобилна платформа само няколко реда код. Този стартиращ старт беше много хубав, когато първоначално оценявахме Firebase. Успяхме да съберем доказателство за концепция за няколко часа с много малко включено обучение в сравнение с други опции на масата.

Когато сте готови за по-усъвършенстване и контрол, FirebaseUI все още е полезен, тъй като предоставя и класове за събиране на данни от по-ниско ниво FUIArray и FUIIndexArray, които ви позволяват да управлявате неща като заглавки на раздели и други дисплеи с нечетни топчета.

Пропуснах ли нещо? Споделете своето!