Brugerens startside i vores app, Juster

Sådan byggede vi vores første fuld-stack JavaScript-webapp på tre uger

En simpel trin-for-trin-guide til at gå fra idé til implementeret app

Mine tre måneder med kodning af bootcamp ved Grace Hopper-programmet er afsluttet, og titlen på denne artikel er faktisk ikke helt sand - jeg har nu bygget tre full-stack apps: en e-handel butik fra bunden, en personlig hackathon-projekt efter eget valg og til sidst et tre-ugers capstone-projekt. Dette capstone-projekt var langt det mest intensive - en tre ugers rejse med to holdkammerater - og det er min stolteste succes fra bootcamp. Det er den første robuste, komplekse app, jeg nogensinde har bygget og designet.

Som de fleste udviklere ved, kan det være overvældende at gå i gang med oprettelsen af ​​din første full-stack-app, selv når du "ved, hvordan du koder". JavaScript-økosystemet er utroligt stort: ​​med pakkeadministratorer, moduler, build-værktøjer, transpilere, databaser, biblioteker og beslutninger, der skal træffes om dem alle, er det ikke underligt, at så mange spirende kodere aldrig bygger noget ud over Codecademy-tutorials. Derfor vil jeg lede dig gennem en trinvis guide over de beslutninger og skridt, som mit team tog for at oprette vores live app, Align.

For det første noget kontekst. Align er en webapp, der bruger en intuitiv tidslinjegrænseflade til at hjælpe brugere med at sætte langsigtede mål og styre dem over tid. Vores stak inkluderer ildbase til back-end-tjenester og reaktion i frontend. Mine holdkammerater og jeg forklarer mere i denne korte video:

Så hvordan gik vi fra dag 1, da vi blev tildelt vores hold, til den endelige live-app? Her er en oversigt over de trin, vi har taget:

Trin 1: Idé

Det første skridt var at finde ud af, hvad vi nøjagtigt ønskede at bygge. I mit tidligere liv som konsulent hos IBM ledte jeg ideation workshops med virksomhedsledere. På baggrund heraf foreslog jeg for min gruppe den klassiske brainstormingsstrategi, der blev post-it, hvor vi alle klipper så mange ideer vi kan - endda 'dumme' - så folks hjerner bevæger sig og ingen undgår at udtale ideer ud af frygt.

Efter at have genereret et par dusin app-ideer, sorterede vi dem i kategorier for at få en bedre forståelse af, hvilke temaer vi kollektivt var begejstrede for. I vores gruppe så vi en klar tendens mod ideer omkring selvforbedring, målsætning, nostalgi og personlig udvikling. Fra det tidspunkt fins vi til sidst på en bestemt idé: et personligt betjeningspanel til indstilling og styring af langsigtede mål med elementer af hukommelsesopbevaring og datavisualisering over tid.

Derfra skabte vi et sæt brugerhistorier - beskrivelser af funktioner, som vi ønskede at have, fra et slutbrugerperspektiv - for at belyse, hvad vi nøjagtigt ønskede, at vores app skulle gøre.

Trin 2: Trådramme UX / UI

Dernæst på en hvid tavle trak vi ud de grundlæggende synspunkter, vi forestillede os i vores app. Vi inkorporerede vores sæt brugerhistorier for at forstå, hvordan disse synspunkter ville fungere inden for rammerne af en skelet-app.

Disse skitser sikrede, at vi alle var på den samme side og leverede en visuel plan fremad for, hvad vi præcist arbejdede for.

Trin 3: Vælg en datastruktur og databasetype

Det var nu tid til at designe vores datastruktur. Baseret på vores wireframes og brugerhistorier, oprettede vi en liste i et Google-dokument over de modeller, vi har brug for, og hvilke attributter hver skal indeholde. Vi vidste, at vi havde brug for en 'mål' -model, en 'bruger'-model, en' milepæl '-model og en' checkin '-model, såvel som til sidst en' ressource'-model og en 'upload'-model.

Vores første skitse af vores datamodeller

Efter uformelt at have tegnet modellerne, var vi nødt til at vælge en type database: 'relationel' vs. 'ikke-relationel' (a.k.a. 'SQL' vs. 'NoSQL'). Mens SQL-databaser er tabelbaserede og har behov for foruddefinerede skemaer, er NoSQL-databaser dokumentbaserede og har dynamisk skema for ustrukturerede data.

Til vores brugssag har det ikke meget, om vi brugte en SQL eller en No-SQL-database, så vi i sidste ende valgte Googles sky NoSQL-database Firebase af andre grunde:

  1. Det kunne indeholde uploads af brugerbilleder i sin skylager
  2. Det inkluderede WebSocket-integration til realtidsopdatering
  3. Det kunne håndtere vores brugergodkendelse og tilbyde let OAuth-integration

Når vi valgte en database, var det på tide at forstå forholdet mellem vores datamodeller. Da Firebase er NoSQL, kunne vi ikke oprette sammenlægningstabeller eller oprette formelle relationer som "Checkins hearTo Goals". I stedet havde vi brug for at finde ud af, hvordan JSON-træet ville se ud, og hvordan objekterne ville blive indlejret (eller ikke). I sidste ende strukturerede vi vores model sådan:

Vores endelige Firebase-dataskema for Goal-objektet. Bemærk, at milepæle & checkins er indlejret under mål.

(Bemærk: Firebase foretrækker flade, normaliserede datastrukturer for effektivitet, men for vores brugssag var det mest fornuftigt at reden det, da vi aldrig ville trække et mål fra databasen uden dens barns milepæle og checkins.)

Trin 4: Indstil Github og en smidig arbejdsgang

Vi vidste fra starten af, at at holde organiseret og praktisere smidig udvikling ville tjene os godt. Vi oprettede en Github-repo, hvorpå vi forhindrede, at vi smeltede sammen til at tvinge os selv til at gennemse hinandens kode.

Vi oprettede også et smidigt bord på Waffle.io, som er gratis og har let integration med Github. På vaffeltavlen listede vi vores brugerhistorier såvel som bugs, som vi vidste, at vi var nødt til at rette op. Senere, da vi begyndte at kode, opretter vi hver gitgrene til den brugerhistorie, vi arbejdede med, og flyttede den fra svømmebane til svømmebane, da vi gjorde fremskridt.

Vi begyndte også at holde ”stand-up” -møder hver morgen for at diskutere den foregående dags fremskridt, og eventuelle blokerere, som hver af os stød på. Dette møde besluttede ofte dagens flow - hvem der skulle være parprogrammering, og hvem der ville arbejde på et emne-solo.

Jeg kan varmt anbefale en slags struktureret arbejdsgang som denne, da det gjorde det muligt for os klart at definere vores prioriteringer og gøre effektive fremskridt uden nogen interpersonel konflikt.

Trin 5: Vælg & download en kedelplade

Fordi JavaScript-økosystemet er så kompliceret, valgte vi ikke at bygge vores app fra absolut jordnul. Det føltes unødvendigt at bruge værdifuld tid på at tilslutte vores Webpack-build-scripts og læsere, og vores symlink, der pegede på vores projektmappe. Mit team valgte Firebones-skelet, fordi det passer til vores brugssag, men der er mange open source-skeletindstillinger, der er tilgængelige at vælge imellem.

Trin 6: Skriv back-end API-ruter (eller Firebase-lyttere)

Hvis vi ikke brugte en skybaseret database, ville det have været tid til at begynde at skrive vores back-end Express-ruter for at stille anmodninger til vores database. Men da vi brugte Firebase, som allerede er i skyen og har en anden måde at kommunikere med kode på, arbejdede vi bare med at opsætte vores første succesrige databaselytter.

For at sikre, at vores lytter fungerede, kodede vi en grundlæggende brugerformular til oprettelse af et mål og så, at faktisk, da vi udfyldte formularen, blev vores database live-opdateret. Vi var forbundet!

Trin 7: Lav et "Proof Of Concept"

Vores næste trin var at skabe et "bevis på koncept" til vores app eller en prototype af de mest vanskelige grundlæggende funktioner til at implementere, hvilket demonstrerer, at vores app i sidste ende kunne eksistere. For os betød dette at finde et front-bibliotek, der tilfredsstillende gengiver tidslinjer og tilslutter det til Firebase med succes for at få vist nogle frødata i vores database.

Grundlæggende sejr.JS-tidslinjer

Vi fandt Victory.JS, et React-bibliotek bygget på D3, og brugte en dag på at læse dokumentationen og sammensætte et meget grundlæggende eksempel på en VictoryLine-komponent og en VictoryScatter-komponent til visuelt at vise data fra databasen. Det virkede faktisk! Vi var klar til at bygge.

Trin 8: Kode funktionerne ud

Endelig var det tid til at opbygge al den spændende funktionalitet i vores app. Dette er et kæmpe trin, der naturligvis vil variere meget afhængigt af den app, du personligt bygger. Vi kiggede på vores wireframes og begyndte at kode de individuelle brugerhistorier i vores vaffel. Dette omfattede ofte berøring af både front-end og back-end-kode (for eksempel at oprette en front-end form og også forbinde den til databasen). Vores funktioner varierede fra større til mindre og inkluderede ting som:

  • evnen til at skabe nye mål, milepæle og checkins
  • evne til at slette mål, milepæle og checkins
  • evnen til at ændre en tidslinjes navn, farve og detaljer
  • mulighed for at zoome ind på tidslinjer
  • evne til at tilføje links til ressourcer
  • evne til at uploade medier
  • evne til at boble ressourcer og medier fra milepæle og checkins til deres tilknyttede mål
  • integration af rich text editor
  • bruger tilmelding / godkendelse / OAuth
  • popover for at se indstillinger for tidslinjer
  • indlæser skærme

Af åbenlyse grunde tog dette trin størstedelen af ​​vores tid - denne fase er, hvor det meste af den kødfulde kode skete, og hver gang vi afsluttede en funktion, var der altid mere at bygge ud!

Trin 9: Vælg og kode designskemaet

Når vi havde en MVP af den funktionalitet, vi ønskede i vores app, var det tid til at rydde op og gøre det smukt. Mit team brugte Material-UI til komponenter som formfelter, menuer og login-faner, som sikrede, at alt så slankt, poleret og sammenhængende ud, uden meget dybtgående designviden.

Dette var en af ​​mine yndlingsfunktioner til at kode ud. Dens skønhed er så tilfredsstillende!

Vi brugte et stykke tid på at vælge et farveskema og redigere CSS, hvilket gav os en dejlig pause fra kodning i skyttegravene. Vi designede også et logo og uploadede en favorit.

Trin 10: Find og squash bugs

Selvom vi skulle have brugt testdrevet udvikling fra begyndelsen, efterlod tidsbegrænsninger os meget dyrebar tid til andet end funktioner. Dette betød, at vi brugte de sidste to dage på at simulere enhver brugerstrøm, vi kunne tænke på, og jage vores app efter bugs.

Denne proces var ikke den mest systematiske, men vi fandt masser af bugs til at holde os travlt, inklusive en bug, hvor indlæsningsskærmen ville vare ubestemt i visse situationer, og hvor ressourcekomponenten var ophørt med at fungere helt. At rette bugs kan være irriterende, men når det endelig fungerer, er det yderst tilfredsstillende.

Trin 11: Distribuer live-appen

Det sidste trin var at implementere vores app, så den ville være tilgængelig live! Fordi vi brugte Firebase til at gemme vores data, distribuerede vi til Firebase Hosting, som var intuitivt og enkelt. Hvis din bagenden bruger en anden database, kan du bruge Heroku eller DigitalOcean. Generelt er installationsvejledninger let tilgængelige på hostingwebstedet.

Vi købte også et billigt domænenavn på Namecheap.com for at gøre vores app mere poleret og let at finde.

Og det var det - vi var pludselig medskabere af en rigtig live full-stack app, som nogen kunne bruge! Hvis vi havde en længere bane, ville trin 12 have været at køre A / B-test på brugere, så vi bedre kunne forstå, hvordan faktiske brugere interagerer med vores app, og hvad de gerne vil se i en V2.

For tiden er vi imidlertid glade for det endelige produkt og den umådelige viden og forståelse, vi har opnået gennem denne proces. Tjek Juster her!

Team Align: Sara Kladky (til venstre), Melanie Mohn (center) og mig selv.

- -
Hvis du nød dette stykke, ville jeg elske det, hvis du rammer det grønne hjerte - så andre måske snubler over det. Tjek gerne kildekoden for Align, og følg mig på Github såvel som mine badass-teammedlemmer, Sara Kladky og Melanie Mohn.