Kuinka käsitellä tuntemattomia ja tehdä oletuksia pilvitietokannan suunnittelussa

Kuva: Chance Anderson Unsplashin kautta

Skenaario: kenkälaatikko vai sosiaalinen sovellus?

Oletetaan, että olet kehittäjä, joka haluaa rakentaa muistiinpanojen sovelluksen. Katsotaanpa yhtä ominaisuustietoa, jolla on valtavia vaikutuksia taustaasi. Muistiinpanon kirjoittamiseksi sovelluksesi on voitava tallentaa tiedot.

Tietueen tallentaminen tietokantaan on suoraviivaista. Keskeiset kysymykset ovat:

  • Kenen on käytettävä tätä levyä?
  • Onko se vain käyttäjän vai jakaako käyttäjän muiden kanssa?
  • Onko tuotteesi kenkälaatikkosovellus vai sosiaalinen sovellus?

Jos haluat, että muistiinpanot ovat tekijän yksityisiä, saatat päätellä, että teet kenkälaatikkosovelluksen. Tämä tarkoittaa, että kaikki tiedot menevät yksityiseen tietokantaan (tietokanta).

Jos aiot sovelluksesi jakaa muistiinpanoja muiden kanssa, saatat päätellä, että sen pitäisi olla julkinen tietokanta.

Mutta tiedätkö mikä se on ennen kuin aloitat?

Ja mitä teet, jos sinun on vaihdettava tuotetta menemällä? Julkinen ja yksityinen tietokanta eivät ole ensimmäinen asia, josta useimmat kehittäjät ajattelevat sovellusta rakentaessaan. Kohdimme nämä kysymykset, kun rakensimme taustatuotetta kehittäjillemme Skygearille.

Koska kokemuksemme sovellusten rakentamisesta asiakkaille oletettiin, että tietokanta oli oikein valittu. Ja että käyttäjän tietäisi kuinka valita.

Kuinka rakentaa taustat kehittäjille, jotka eivät ole vielä varmoja tuotteistaan?
 Tai niille, jotka haluavat pitää vaihtoehtonsa auki tulevaisuudessa?

Projektin teknisenä johtajana haluaisin kertoa kanssamme päätöksentekoprosessistamme 2 vuotta sitten. Toivon, että se auttaa tulevia kehitysryhmiä lähestymään tuntemattomia ja oletuksia.

Miksi aloimme miettiä yksityisiä tai julkisia tietokantoja?

Monet sovellukset vaativat taustatiedot käyttäjän tietojen tallentamiseksi ja kyselyiksi. Taustan rakentaminen on paljon kovaa työtä, ja katsokaamme sitä - ei niin mukava luoda. Skygear on avoimen lähdekoodin palvelimettoman taustamme. Se auttaa käsittelemään mobiili- ja verkkosovellusten yleisiä kehitysominaisuuksia.

Ominaisuus, josta puhun, on Cloud DB, johon tallennat ja kysyt käyttäjätietoja. Kun aloimme suunnitella Cloud DB: tä, kysyimme itseltämme, kuinka erilaiset sovellukset tallentavat ja kysyvät käyttäjätietoja.

Tutkimme inspiraatiota yrityksemme mobiilisovellusportfoliosta. Yrityksemme tekee kaiken kuluttajasovelluksista sähköisen kaupan sovelluksiin. Joten ryhmitelimme ne kenkälaatikko- ja sosiaalisovelluksiin.

Kenkäsovellussovellukset tallentavat henkilötietoja, jotka käyttäjä haluaa pitää yksityisenä. Esimerkiksi Spentable-sivuprojektimme auttaa käyttäjää seuraamaan heidän päivittäisiä kulujaan. Sovelluksessa tallennettujen tietojen on tarkoitus olla yksityisiä kenkälaatikossa.

Mutta on juttuja, jotka haluamme jakaa julkisesti tai ystävien kanssa. Tämä tarkoittaa myös, että käyttäjän on valvottava sitä, kuka voi lukea tietojaan. Nämä kaksi tyyppistä sovellusta esittävät haasteen suunnitellessamme Skygear's Cloud DB: n. Halusimme tehdä tietojen tallentamisesta Cloud DB: hen mahdollisimman helppoa. Kenkälaatikkosovellusten osalta kaikki kehittäjät tarvitsevat tietokannan, jossa jokainen käyttäjä voi nähdä vain lisäämänsä tiedot. Silti sosiaalisissa sovelluksissa kehittäjät tarvitsevat ominaisuuksia, kuten ACL (kulunvalvonta). Kuinka voimme tehdä asioista yksinkertaisia ​​kummankin tyyppisten sovellusten kehittäjille?

Ottaa kakku ja syö myös sitä

Päätimme ratkaista tämän ongelman ottamalla Cloud DB: hen käyttöön useiden tietokantojen käsitteen: yksityinen DB ja julkinen DB. Jokaisella käyttäjällä on yksityinen tietokanta tietojen sijoittamista varten, ja nämä tiedot ovat vain saman käyttäjän käytettävissä. Sovelluksella on myös yksi julkinen tietokanta, joka on jaettu kaikkien käyttäjien kesken.

Kenkälaatikkosovellusten kehittäjä pystyy keskittymään tietojen tallentamiseen ja hakemiseen murehtimatta käyttöoikeuksista, koska yksityisen tietokannan tiedot ovat aina yksityisiä.

Yksityinen DB ei kuitenkaan toimi lainkaan sosiaalisissa sovelluksissa. Sosiaalisten sovellusten kehittäjien tulee laittaa tiedot julkiseen tietokantaan, koska sosiaalisten sovellusten tiedot on tarkoitettu jaettavaksi.

Ennen kuin lisäsimme tukea ACL: lle, tämä yksinkertainen erottelu julkisesta ja yksityisestä tiedosta palveli meitä (ja käyttäjiämme erittäin hyvin. Kaikki yksityisessä DB: ssä on todella yksityistä, kun taas kaikki on julkista. DB on todella julkinen.

"Kaikki on julkista" ei ole tarpeeksi hyvä. Useimmissa sosiaalisissa sovelluksissa käytetään tapauksia, joissa tietoja jaetaan vain ystäväryhmän kesken.

ACL on toinen vaikea ja mielenkiintoinen aihe, jonka pitäisi olla sen oma artikkeli.

Meillä ei voisi olla parasta molemmista tietokannoista

DB: n erottaminen yksityiseksi ja julkiseksi oli hyvä idea. Ajattelimme heidän tukevan käyttötapausta useimmissa sovelluksissa.

Mutta varhaiset käyttöönottajat pitivät yksityisiä ja julkisia vaihtoehtojamme hämmentävänä.

Varhaiset käyttäjät antoivat meille arvokasta palautetta. Kiinnitimme huomiota myös saamiin tukikysymyksiin. Tämän olemme oppineet kehittäjäpalautteesta, kun he käyttivät Cloud DB: tä:

  1. Kehittäjille ei ole selvää, mitä he rakentavat aluksi
    Vaikka voi olla ilmeistä, minkälainen sovelluskehittäjä on luonut katsomalla tuotetta takautuvasti, se ei ole selvää get-go-toiminnasta. On vaikeaa, ellei mahdotonta pakottaa kehittäjää päättämään, tekevätkö he kenkälaatikon vai sosiaalisen sovelluksen alussa.
  2. Kehittäjät haluavat vain aloittaa nopeasti
    Haluamme, että kehittäjät oppivat perusasiat mahdollisimman nopeasti. On liikaa kysyä uusilta käyttäjiltä se, että sinun on opittava vielä yksi käsite valita käytettävä tietokanta ennen kuin he voivat tallentaa ja hakea tietoja.
  3. Päätöstä julkisesta tai yksityisestä DB: stä, kun se on tehty, ei ole helppo kääntää
    Oletetaan, että kehittäjä aloitti kenkälaatikkosovelluksen idean kanssa ja he panivat kaiken yksityiseen tietokantaan. Myöhemmin he saattavat huomata, että heidän pitäisi tehdä sovelluksesta sosiaalinen. Tietoja ei ole helppo siirtää, kun ne on laitettu tiettyyn tietokantaan.
  4. Luvat ovat yleensä ajatuksen jälkikäteen
    Tietoturva on yrityksessämme ensisijainen tavoite. Mutta tietoturva ei ole ensimmäinen asia, joka tulee kehittäjän mieleen. Varsinkin kun he vain tekevät konseptin prototyypin. He haluavat keskittyä ensin toiminnallisuuteen ja huolehtia turvallisuudesta myöhemmin.

Noutomme

Mietimme jatkuvasti, kuinka voisimme parantaa tuotteitamme. Voisimme tehdä parempia ohjelmistoarkkitehtuurin, käyttäjän dokumentoinnin ja helppokäyttöisyyden suhteen. Ajattelemme joskus sitä, mitä tekisimme, jos voisimme kelata taaksepäin kaksi vuotta aloittaaksesi alusta. Mutta tässä me sanomme entisille itsellemme:

  1. Jos kehittäjät tuntevat jo olemassa olevan konseptin, ota se käyttöön
    Suurin osa kehittäjistä tuntee tietokannan käsitteen. Se on jonkinlainen säilö, johon kehittäjät voivat tallentaa sisältöä. He voivat myös hakea tietoja ja tukea CRUD (Luo, lue, päivitä ja poista) -ominaisuutta.
    Koska kehittäjät ovat jo tietoisia tietokannan käsitteestä, he löytäisivät Cloud DB: n yhden tietokannan suoraan käytettäväksi.
  2. Esittele uusia konsepteja, kun kehittäjät ovat niihin varautuneet
    Tämä ajatus on itse asiassa toinen tapa sanoa, että meidän pitäisi tehdä oppimiskäyrästä mahdollisimman helppo. Skygear oli omalla tavallaan prototyyppi. Olemme juuri julkaissut V1.0 !.
    Et koskaan halua tehdä varhaisten adoptoijien elämää vaikeaksi. Se, että joudut oppimaan kaiken, ennen kuin kehittäjät voivat tehdä mitään, ei sovellu tuotteesta hyvin. Ennen kuin kehittäjien on pohdittava tietolupia, heidän ei tarvitse tietää yksityisen ja julkisen tietokannan välisestä erotuksesta. Meidän pitäisi antaa käyttäjien päästä alkuun yleisistä konsepteista ensin tutustua uuteen alustaan.
    Vasta kun ne ovat mukavia, meidän pitäisi ottaa käyttöön uusia konsepteja tarjotaksemme lisää vaihtoehtoja. Tässä tapauksessa kehittäjälle ei ole haittaa huomata tarvitsevansa ACL: ää, joten uusi konsepti on luonnollinen seuraava askel sen jälkeen kun he ovat oppineet käyttämään Cloud DB: tä.

Mitä opimme

Kun aloimme työskennellä Skygearilla kaksi vuotta sitten, halusimme rakentaa kick-ass-tuotteen 2–4 vanhempien kehittäjien kanssa. Meillä oli valmiita testaajia omilta sisäisiltä kehittäjiltämme, jotka antoivat paljon kriittistä palautetta. Ajattelimme käyttää kokemustamme verkko- ja mobiilisovellusten kehittämisessä tehdä parempia päätöksiä työkalujen suunnittelusta muille kehittäjille.

Mutta kokemuksemme loi myös oletuksia siitä, mitä odottaa käyttäjien tietävän ennen tuotteemme käyttöä.

Hyvä asia siitä, että saimme käyttäjän palautetta Cloud DB: stä mennessämme, oli se, että oppimme oletuksemme olevan virheellisiä. Arvokkain oppitunti oli nöyrä muistutus käynnistyksen perusperiaatteesta. Kokemuksestamme riippumatta emme usein tiedä tarkalleen mitä rakennamme.

Tietenkin se ei estä meitä yrittämästä rakentaa kyseisen filosofin kiviä helpottamaan joka tapauksessa kehittäjäkumppaneidemme elämää. Kuten perustajani Ben sanoi, yksi hänen tuottoisimmista päivistään oli, kun hän heitti 1000 riviä koodia pois.

Haluaisin kiittää kollegaani cheungpatia, joka työskenteli Cloud DB: n parissa kanssani ja auttoi tämän kappaleen kirjoittamisessa.

Tiimini mielelläni kuulee kriittistä palautetta Skygearista. Katso myös dokumentaatiomme ja GitHub-reposiimme nähdäksesi kuinka keskustelemme Skygear-ominaisuuksista.