Как да се справим с неизвестни и да правим предположения при проектирането на база данни в облак

Снимка на Chance Anderson чрез Unsplash

Сценарий: Shoebox или социално приложение?

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

Запазването на запис в база данни е направо напред. Ключовите въпроси са:

  • Кой ще трябва да има достъп до този запис?
  • Ще бъде само вашият потребител или ще го сподели с други потребители?
  • Дали вашият продукт ще бъде приложение за обувки или социално приложение?

Ако възнамерявате бележките да бъдат частни за автора, можете да заключите, че правите приложение за обувки. Това означава, че всички данни отиват в частна БД (база данни).

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

Но ще разберете ли кое е преди да започнете?

И какво ще направите, ако трябва да смените продукта си, докато вървите? Публичната DB и частната DB не са първото нещо, за което повечето разработчици се замислят, когато създават приложение. С тези въпроси се сблъскахме, когато изграждахме нашия бек-енд продукт за нашите разработчици, Skygear.

Поради нашия опит в изграждането на приложения за клиенти, ние предположихме, че има правилен избор на база данни. И че нашият потребител ще знае как да избере.

Как да изградите бек-енд за разработчици, които все още не са сигурни в нуждите на своите продукти?
 Или за тези, които искат да запазят своите възможности отворени в бъдеще?

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

Защо започнахме да мислим за частни срещу публични БД?

Много приложения изискват бек-енд за съхранение и заявка на потребителски данни. Задният край е много тежък труд за изграждане и, нека си признаем - не е толкова приятен за създаване. Skygear е бек-енд сървърът ни с отворен код. Той помага за адресиране на общи функции за развитие на мобилни и уеб приложения.

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

Разгледахме портфолиото за мобилни приложения на нашата компания за вдъхновение. Нашата компания прави всичко - от потребителски приложения до приложения за електронна търговия. Така ги групирахме в приложения за „обувки“ и „социални“.

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

Но има неща, които искаме да споделим публично или с приятели. Това също означава, че потребителят трябва да контролира кой може да чете техните данни. Тези два вида приложения представляват предизвикателство в начина, по който проектирахме Skygear Cloud DB. Искахме да направим съхранението на данни в Cloud DB възможно най-лесно. За приложенията за кутии за обувки, всички програмисти се нуждаят от база данни, в която всеки потребител може да вижда само данните, които въвежда. И все пак в социалните приложения разработчиците се нуждаят от функции като ACL (контрол на достъпа). Как можем да направим нещата прости за разработчиците на двата вида приложения?

Като имаме нашата торта и я ядем също

Решихме да разрешим този проблем, като въведем концепцията за множество бази данни в облачната БД: частна БД и публична БД. Всеки потребител има частна DB за въвеждане на данни и тези данни са достъпни само за същия потребител. Приложението има и един публичен DB, който се споделя между всички потребители.

Разработчикът на приложения за обувки е в състояние да се съсредоточи върху запазването и извличането на данните, без да се притеснява от разрешения, тъй като данните в частната БД винаги са частни.

Но частният DB изобщо не работи за социални приложения. Разработчиците на социални приложения трябва да поставят данни в публичната DB, тъй като данните в социалните приложения са предназначени за споделяне.

Преди да добавим поддръжка за ACL, това просто разграничение за публични и частни данни ни послужи (и нашите потребители много добре. Всичко в частния DB е наистина частно, докато всичко е публично БД е наистина публично.

„Всичко е публично“ не е достатъчно добро. Повечето социални приложения имат случаи на използване, че данните се споделят само сред група приятели.

ACL е друга трудна и интересна тема, която трябва да бъде собствената му статия.

Не можехме да имаме най-доброто от двете бази данни

Разделянето на БД на частни и публични беше добра идея. Мислехме, че те поддържат случая на използване за повечето приложения.

Но ранните осиновители намериха нашите частни и публични възможности за объркващи.

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

  1. Не е очевидно за разработчиците какво строят в началото
    Макар че може да е очевидно какъв тип разработчици на приложения е направил, като гледа продукта със задна дата, това не е очевидно от първа стъпка. Принуждаването на програмиста да реши дали правят кутия за обувки или социално приложение в началото е трудно, ако не и невъзможно.
  2. Разработчиците просто искат да започнат бързо
    Искаме разработчиците да научат основите възможно най-бързо. Трябва да научите още една концепция, за да изберете каква БД да използвате, преди да могат действително да запазват и извличат данни, е твърде много, за да поискате нови потребители.
  3. Веднъж взето решение за публична или частна БД не е лесно да се промени
    Да предположим, че един програмист е започнал с идеята за приложение за обувки и са поставили всичко в частната БД. По-късно те могат да разберат, че вместо това трябва да направят приложението социално. Не е лесно да мигрирате данни, след като са поставени в конкретна БД.
  4. Разрешенията обикновено са след мисли
    Сигурността на данните е приоритет в нашата компания. Сигурността на данните обаче не е първото нещо, което идва на ум на разработчик. Особено, когато те просто правят прототип на доказателство за концепция. Те искат първо да се съсредоточат върху функционалността и по-късно да се грижат за сигурността.

Нашите отводи

Винаги мислим как бихме могли да направим нашите продукти по-добри. Бихме могли да се справим по-добре по отношение на софтуерната архитектура, документацията на потребителя и лекотата на използване. Понякога мозъчна атака какво бихме направили, ако успеем да върнем часовника две години, за да започнем отначало. Но ето какво бихме казали на нашите бивши себе си:

  1. Ако разработчиците вече са запознати със съществуваща концепция, приемете я
    Повечето разработчици са запознати с концепцията за база данни. Това е някакъв контейнер, в който разработчиците могат да записват съдържание. Те също могат да извличат данни и да поддържат свойството CRUD (Създаване, четене, актуализиране и изтриване).
    Тъй като разработчиците вече са запознати с концепцията за база данни, те биха намерили единна база данни в Cloud DB направо да се използва.
  2. Въвеждайте нови концепции, когато разработчиците са подготвени за тях
    Тази идея всъщност е друг начин да кажем, че трябва да направим кривата на обучение възможно най-лесна. Skygear беше прототип по свой начин. Току-що стартирахме V1.0 !.
    Никога не искате да затруднявате живота на ранните си осиновители. Трябва да научите всичко, преди разработчиците да могат да направят всичко, не работи добре от продуктова гледна точка. Докато разработчиците не трябва да мислят за разрешение за данни, те не трябва да знаят за разликата между частна БД и публична БД. Трябва да оставим нашите потребители да започнат първо с общите концепции, за да се запознаят с нова платформа.
    Едва след като им е удобно, трябва да въведем нови концепции, за да предоставим повече възможности. В този случай няма вреда за един програмист да открие, че се нуждаят от ACL, така че новата концепция е естествена следваща стъпка, след като са се научили как да използват Cloud DB.

Какво научихме

Когато започнахме да работим над Skygear преди две години, ние искахме да създадем ритмичен продукт с 2–4 от нашите старши разработчици. Имахме готови тестери от собствени собствени разработчици, които дадоха много критични отзиви. Решихме, че използваме опита си в разработването на уеб и мобилни приложения, за да вземем по-добри решения за това как да проектираме инструменти за други разработчици.

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

Хубавото в получаването на отзиви на потребителите за Cloud DB, докато отидохме е, че научихме, че нашите предположения са неверни. Най-ценният ни урок беше смирителното напомняне на основен принцип на стартиране. Без значение от нашия опит, ние често не знаем какво точно изграждаме.

Разбира се, това не ни спира да се опитваме да изградим този философски камък, за да улесним живота на колегите си разработчици. Както каза моят съосновател Бен, един от най-продуктивните му дни беше, когато той хвърли 1000 реда код.

Бих искал да благодаря на колегата cheungpat, който работеше в облачната DB с мен и ми помогна да напиша това парче.

Моят екип би искал да чуе критичните ви отзиви за Skygear. Вижте и нашата документация и репортажи на GitHub, за да видите как обсъждаме функциите на Skygear.