Kuidas käsitleda tundmatuid ja teha eeldusi pilveandmebaasi kujundamisel

Foto: Anders Anderson Unsplashi kaudu

Stsenaarium: kingakast või suhtlusrakendus?

Oletame, et olete arendaja, kes soovib luua märkmete tegemise rakenduse. Vaatame ühte funktsiooni detaili, millel on tohutu mõju teie taustale. Märkme kirjutamiseks peab teie rakendus saama andmeid salvestada.

Kirje salvestamine andmebaasi on lihtne. Põhiküsimused on järgmised:

  • Kes peab sellele dokumendile juurde pääsema?
  • Kas see on ainult teie kasutaja või jagab teie kasutaja seda teistega?
  • Kas teie toode on kingakarbi rakendus või sotsiaalne rakendus?

Kui soovite, et märkmed oleksid autori jaoks privaatsed, võite järeldada, et teete kingakarbi rakendust. See tähendab, et kõik andmed lähevad privaatsesse andmebaasi (andmebaas).

Kui kavatsete oma rakendusel märkmeid teistega jagada, võite järeldada, et see peaks olema avalik DB.

Kuid kas saate enne alustamist teada, mis see on?

Ja mida teete siis, kui peate oma toodet kohe muutma? Avalik ja privaatne DB ei ole esimene asi, mida enamik arendajaid rakenduse loomisel mõtleb. Selle küsimusega puutusime kokku, kui me oma arendajatele Skygearile tagatooteid ehitasime.

Kuna meil on klientide jaoks rakenduste loomise kogemus, eeldasime, et andmebaaside valik on õige. Ja et meie kasutaja teaks, kuidas valida.

Kuidas luua tagavara arendajatele, kes pole veel kindlad oma tootevajaduses?
 Või neile, kes soovivad tulevikus oma võimalusi avatuna hoida?

Projekti juhtiva juhina tahaksin jagada teiega meie 2 aasta tagust otsustusprotsessi. Loodan, et see aitab tulevastel arendusmeeskondadel läheneda tundmatustele ja eeldustele.

Miks me hakkasime mõtlema privaatsete või avalike DB-de peale?

Paljud rakendused vajavad kasutajaandmete salvestamiseks ja päringute tegemiseks tagavara. Taustmaterjali ehitamine on palju rasket tööd ja, olgem ausad, pole selle loomine nii nauditav. Skygear on meie avatud lähtekoodiga serverivaba taust. See aitab käsitleda mobiili- ja veebirakenduste ühiseid arendusfunktsioone.

Funktsioon, millest ma räägin, on meie Cloud DB, kus te salvestate ja küsite kasutaja andmeid. Kui me Cloud DB-d kavandama hakkasime, küsisime endalt, kuidas erinevad rakendused kasutaja andmeid salvestavad ja päringuid teevad.

Vaatasime inspiratsiooni meie ettevõtte mobiilirakenduste portfellist. Meie ettevõte teeb kõike alates tarbijarakendustest kuni e-kaubanduse rakendusteni. Niisiis jagasime nad rühmadesse „shoe-box” ja „social”.

Kingakarbirakendused salvestavad isikuandmeid, mida kasutaja soovib privaatsena hoida. Näiteks aitab meie kõrvalprojekt Spentable kasutajal jälgida nende igapäevaseid kulutusi. Rakenduses salvestatud andmed on mõeldud privaatseks, kingakarbis.

Kuid on asju, mida tahame avalikult või sõpradega jagada. See tähendab ka seda, et kasutaja peab kontrollima, kes saab nende andmeid lugeda. Need kaks tüüpi rakendused kujutavad endast väljakutset Skygeari Cloud DB kujundamisel. Tahtsime muuta andmete salvestamise Cloud DB-s võimalikult lihtsaks. Kingakarbirakenduste jaoks on arendajatel vaja vaid andmebaasi, kus iga kasutaja saab näha ainult neid andmeid, mille nad sisestavad. Kuid sotsiaalsetes rakendustes vajavad arendajad selliseid funktsioone nagu ACL (juurdepääsu kontroll). Kuidas saaksime asjad mõlemat tüüpi rakenduste arendajatele lihtsaks teha?

Omame oma kooki ja sööme seda ka

Otsustasime selle probleemi lahendada, tutvustades Cloud DB-s mitme andmebaasi kontseptsiooni: privaatne DB ja avalik DB. Igal kasutajal on andmete sisestamiseks privaatne DB ja need andmed on saadaval ainult samale kasutajale. Rakendusel on ka üks avalik DB, mida jagatakse kõigi kasutajate vahel.

Kingakarbirakenduse arendaja suudab keskenduda andmete salvestamisele ja hankimisele, muretsemata lubade pärast, kuna andmed privaatses DB-s on alati privaatsed.

Kuid privaatne DB ei tööta sotsiaalsete rakenduste puhul üldse. Suhtlusrakenduste arendajad peaksid andmed avalikku andmebaasi panema, kuna sotsiaalsete rakenduste andmeid tahetakse jagada.

Enne ACL-i toe lisamist teenis see lihtne eristamine avalikke ja privaatseid andmeid meile (ja meie kasutajatele väga hästi. Kõik privaatses DB-s on tõesti privaatne, samas kui kõik on avalik. DB on tõeliselt avalik.

“Kõik on avalik” pole piisavalt hea. Enamikus sotsiaalsetes rakendustes kasutatakse juhtumeid, kus andmeid jagatakse ainult sõpruskonna vahel.

ACL on veel üks keeruline ja huvitav teema, mis peaks olema selle enda artikkel.

Meil ei oleks mõlemast andmebaasist parimat

Eraldada DB era- ja avalikeks oli hea mõte. Arvasime, et nad toetavad enamiku rakenduste kasutusjuhtu.

Kuid varased kasutuselevõtjad pidasid meie era- ja avalikke võimalusi segaseks.

Meie varasemad kasutajad andsid meile hindamatut tagasisidet. Pöörasime tähelepanu ka saadud tugiküsimustele. Seda õppisime arendajate tagasisidest, kui nad kasutasid meie Cloud DB:

  1. Arendajatele pole alguses selge, mida nad ehitavad
    Ehkki võib tagasiulatuvalt vaadates olla ilmne, millise rakendusearendaja tegi, vaadates seda, ei ole get-go see ilmne. Arendaja sundimine otsustama, kas nad teevad alguses kingakarbi või sotsiaalse rakenduse, on keeruline, kui mitte võimatu.
  2. Arendajad tahavad lihtsalt kiiresti alustada
    Soovime, et arendajad õpiksid põhitõed võimalikult kiiresti. Uute kasutajate küsimiseks on liiga palju vaja õppida veel üks kontseptsioon, et valida, millist andmebaasi kasutada, enne kui nad saavad andmeid tegelikult salvestada ja hankida.
  3. Kui avalikku või eraõiguslikku DB on otsustatud, pole seda kerge tagasi pöörata
    Oletame, et arendaja alustas kingakarbi rakenduse ideega ja nad panid kõik privaatsesse DB-sse. Hiljem võivad nad aru saada, et peaksid selle rakenduse hoopis sotsiaalseks muutma. Andmete migreerimine pärast nende sisestamist konkreetsesse andmebaasi pole lihtne.
  4. Load on tavaliselt järelemõtlemine
    Andmeturve on meie ettevõttes prioriteet. Kuid andmeturve pole esimene asi, mis arendajale meelde tuleb. Eriti kui nad teevad just kontseptsiooni tõestuse prototüüpi. Nad tahavad kõigepealt keskenduda funktsionaalsusele ja hiljem hoolitseda turvalisuse eest.

Meie kaasavõtmised

Mõtleme pidevalt sellele, kuidas saaksime oma tooteid paremaks muuta. Me saaksime tarkvara arhitektuuri, kasutajadokumentatsiooni ja kasutusmugavuse osas paremini hakkama. Mõnikord ajurünnakuid teeme selle suhtes, mida teeksime, kui saaksime kaks aastat tagasi kerida, et uuesti otsast alata. Kuid siin on see, mida me ütleksime oma endistele isikutele:

  1. Kui arendajad on olemasoleva kontseptsiooniga juba tuttavad, siis kasutage seda
    Enamik arendajaid tunneb andmebaasi mõistet. See on mingisugune konteiner, kuhu arendajad saavad sisu salvestada. Samuti saavad nad andmeid hankida ja CRUD-i (luua, lugeda, värskendada ja kustutada) atribuuti toetada.
    Kuna arendajad on andmebaasi mõistega juba tuttavad, leiaksid nad Cloud DB-st ühtse andmebaasi kasutamiseks.
  2. Tutvustage uusi kontseptsioone, kui arendajad on neile ette valmistunud
    See idee on tegelikult teine ​​viis öelda, et me peaksime õppimiskõvera võimalikult lihtsaks tegema. Skygear oli omal moel prototüüp. Käivitasime just V1.0 !.
    Sa ei taha kunagi oma varajaste lapsendajate elu keeruliseks muuta. Kui toote arendajad saavad midagi õppida, siis toote seisukohast see hästi ei õnnestu. Kuni arendajad ei pea mõtlema andmeloa üle, ei peaks nad teadma erinevust era- ja avaliku andmebaasi vahel. Peaksime laskma kasutajatel kõigepealt levinud kontseptsioonidega tutvuma hakata, et tutvuda uue platvormiga.
    Alles pärast nende mugavust peaksime lisavõimaluste pakkumiseks tutvustama uusi kontseptsioone. Sel juhul pole arendajale kahju avastada, et nad vajavad ACL-i, nii et uus kontseptsioon on loomulik järgmine samm pärast seda, kui nad on õppinud Cloud DB kasutamist.

Mida me õppinud oleme

Kui kaks aastat tagasi Skygeari kallal tööd alustasime, tahtsime koos vanemaid arendajaid ehitada kick-ass toote. Meil olid valmis testijad omaenda ettevõttesisestelt arendajatelt, kes andsid palju kriitilist tagasisidet. Arvasime, et kasutame oma kogemusi veebi- ja mobiilirakenduste arendamisel, et teha paremaid otsuseid, kuidas kujundada tööriistu teistele arendajatele.

Kuid meie kogemus lõi ka eeldused selle kohta, mida oodata meie kasutajatelt enne meie toote kasutamist.

Hea mõte Cloud DB-le tagasiside saamise kohta oli see, et saime teada, et meie eeldused olid valed. Meie kõige väärtuslikum õppetund oli alandlik meeldetuletus käivitamise põhiprintsiibi kohta. Olenemata meie kogemusest, ei tea me sageli täpselt, mida me ehitame.

Muidugi, see ei takista meid püüdmast ehitada seda filosoofi kivi, et muuta nagunii arendajate elu lihtsamaks. Nagu mu kaasasutaja Ben ütles, oli üks tema produktiivsemaid päevi, kui ta viskas 1000 koodirida ära.

Tahaksin tunnustada oma kolleegi cheungpat, kes töötas koos minuga Cloud DB kallal ja aitas seda tükki kirjutada.

Minu meeskond sooviks kuulda teie kriitilist tagasisidet Skygeari kohta. Vaadake ka meie dokumentatsiooni ja GitHubi reposid, et näha, kuidas arutame Skygeari funktsioone.