Overgangen fra banebrytende nysgjerrighet til praktisk arbeidshest er ikke en som mange teknologier lager. Gårsdagens eldgamle oppstarter klarer ofte ikke å oppfylle sitt versjon 0.1-løfte. Ikke så for teknologiene som utgjør den voldsomt forkortede MEAN-stakken.
Det var bare for noen få år siden at MongoDB, Express.js, AngularJS og Node.js hevet øyenbrynene alene. Nå har de vokst opp og gått sammen, og sammen gjør de seriøst arbeid, og tyrer ikke et lite antall utviklere fra den store LAMP-leiren. Men hvordan stabler denne nybegynnede MEAN-tingen akkurat opp mot LAMP? Når er det bedre å velge den velprøvde, modne LAMPEN fremfor denne oppstartssamlingen av JavaScript-sentriske teknologier?
Svaret er når enkelheten og den vanlige strukturen gjør livet ditt lettere. MongoDB tilbyr et mer fleksibelt, imøtekommende lag for lagring av data. Node.js gir en bedre forbindelse for å kjøre serveren din, mens Express hjelper med å standardisere hvordan du bygger nettsteder. På klienten gir Angular en ren måte å legge til interaktive funksjoner og AJAX-drevne rike komponenter. Sett dem alle sammen, og de lager en ren, sammenhengende mekanisme for å flytte data fra bruker til diskfarm og tilbake igjen.
Den virkelige forklaringen er imidlertid dypere. Her har vi ni grunner til å gi MEAN et skudd med ditt neste prosjekt. Ikke alle har tid eller budsjett til å kaste ut og omkode det gamle i det nyeste, mest trendy rammeverket, og du bør heller ikke kaste den solide påliteligheten til kamptestede verktøy som Apache, MySQL eller PHP. Men for grønne feltprosjekter som kan dra nytte av fleksibilitet, enkelhet og ytelse, kan det å gjøre MEAN gjøre livet ditt bedre enn du tror.
MongoDB er bygget for skyen
Hvis webapp-planene dine inkluderer å gjøre godt på lønnene per CPU-løftet til skyen, tilbyr MEAN-stakken et overbevisende databaselag i MongoDB. Denne moderne databasen er utstyrt med automatisk skjæring og full klyngestøtte, rett ut av esken. Plugg inn MongoDB og den sprer seg over klyngen din av servere for å tilby failover-støtte og automatisk replikering. Med tanke på hvor enkelt apper kan utvikles, testes og vert i skyen, er det liten grunn til ikke å vurdere MongoDB for ditt neste prosjekt.
MySQLs struktur er begrensende
Alle som har utviklet eller vedlikeholdt en LAMP-basert app i en lengre periode vet at MySQLs styrke som en relasjonsdatabase til tider kan føles litt fengslende. Som alle relasjonsdatabaser tvinger MySQL deg til å skyve dataene dine inn i tabeller. Dette er ikke et problem hvis hver eneste oppføring passer i nøyaktig samme format, men hvor ofte er verden så sjenerøs? Hva om to personer deler samme adresse, men ikke den samme kontoen? Hva om du vil ha tre linjer til adressen i stedet for to? Hvem har ikke prøvd å fikse en relasjonsdatabase ved å skore for mye data i en enkelt kolonne? Ellers slutter du med å legge til enda en kolonne, og tabellen blir ubegrenset.
MongoDB, derimot, tilbyr en dokumentstruktur som er langt mer fleksibel. Vil du legge til en ny bit personlig informasjon i brukerprofilene dine? Bare legg til feltet i skjemaet ditt, rull det sammen med resten av dataene i et JSON-dokument, og skyv det inn i MongoDB-samlingen din. Dette er flott for prosjekter i flux og for å håndtere data som til slutt kan være vanskelig å begrense i tabellform.
Diskplass er billig
Blant de store åpenbaringene av relasjonsdatabaser var JOIN-kommandoen. Med JOIN kan vi spare diskplass ved å fjerne gjentatte felt som by, stat og postnummer. Ved å lagre disse ofte tilgjengelige og gjentatte dataene i separate tabeller som kan inkluderes i fremtidige resultater gjennom en JOIN, holder vi databasen vår ryddig og diskene er slanke.
Men JOINs kan være vanskelig for noen og vanskelig for RAM, og selv om det fortsatt er en god ide å isolere og få tilgang til data i separate tabeller gjennom JOINs, er det ikke så mye behov for å spare diskplass nå som diskstasjoner måles i flere terabyte. Plassen er så billig at noen databasedesignere ender opp med å avnormalisere dataene sine fordi JOINs er for sakte. Når du har gjort det, trenger du ikke så mye en relasjonsdatabase. Hvorfor ikke bruke MongoDB i stedet?
Node.js forenkler serverlaget
Å navigere i de forskjellige lagene i LAMP-stakken kan være en vanskelig dans av mange hatter, en som får deg til å blande gjennom forskjellige konfigurasjonsfiler med forskjellig syntaks. MEAN forenkler dette ved bruk av Node.js.
Vil du endre hvordan appen din ruter forespørsler? Dryss inn litt JavaScript og la Node.js gjøre resten. Vil du endre logikken som brukes til å svare på spørsmål? Bruk JavaScript der også. Hvis du vil omskrive nettadresser eller lage en merkelig kartlegging, er det også i JavaScript. MEAN-stackens avhengighet av Node.js satte denne typen rørledninger alt på ett sted, alt på ett språk, alt i en bunke med logikk. Du trenger ikke å lese mansidene for PHP, Apache og alt annet du legger til i bunken. Mens LAMP-generasjonen har forskjellige konfigurasjonsfiler for alt, unngår Node.js problemet helt. Å ha alt i ett lag betyr mindre forvirring og mindre sjanse for rare bugs skapt av rare interaksjoner mellom flere lag.
MEAN gjør koden isomorf
Enkelheten stopper ikke med å bruke JavaScript på serveren. Ved å gå MEAN kan du også nyte den samme JavaScript-en på klienten og etterlate LAMP-stackens klient / server-schizofreni. Hvis du skriver kode for Node og bestemmer at den er bedre plassert i Angular, kan du enkelt flytte den over, og det er nesten sikkert å kjøre på samme måte. Denne fleksibiliteten gjør programmering av MEAN-baserte apper betydelig enklere. I tillegg, hvis du bemanner et prosjekt, trenger du ikke lete etter en PHP-ekspert og en JavaScript-ekspert eller en front-end og en back-end-spesialist. I stedet er alt JavaScript over bunken.
JSON overalt
Angular og MongoDB snakker begge JSON, i likhet med Node.js og Express. Dataene flyter pent mellom alle lagene uten omskriving eller omformatering. MySQLs opprinnelige format for å svare på spørsmål er vel, det hele. Ja, PHP har allerede koden for å importere MySQL-data og gjøre det enkelt å behandle i PHP, men det hjelper ikke klientlaget. Dette kan være litt mindre for erfarne LAMP-veteraner fordi det er så mange velprøvde biblioteker som enkelt konverterer dataene, men alt virker litt ineffektivt og forvirrende. MEAN bruker det samme JSON-formatet for data overalt, noe som gjør det enklere og sparer tid for omformatering når det går gjennom hvert lag. I tillegg gjør JSONs allestedsnærværing gjennom MEAN-stakken det enklere å jobbe med eksterne API-er: FÅ, manipulere, presentere, POST og lagre alt i ett format.
Node.js er superrask
Apache var flott, men i disse dager er Node.js ofte flat ut raskere. En rekke standarder viser at Node.js gir bedre ytelse, mens de gjør mye mer. Kanskje det er alderen på koden. Kanskje den hendelsesdrevne arkitekturen Node.js er raskere. Det spiller ingen rolle. I disse dager, spesielt blant utålmodige brukere av mobile enheter, er det viktig å barbere til og med millisekunder av appens ytelse, og Node.js kan gjøre det, samtidig som det tilbyr en komplett Turing-mekanisme for omprogrammering.
Dybde betyr noe
PHP-elskere liker å feste seg til de store kodebibliotekene som ble bygget for dominerende plattformer som WordPress eller Drupal. De har gode grunner til å være stolte, men fordelene deres fordamper etter hvert som Node.js tar igjen.
Node.js pakkehåndterer, NPM, gjør det enda enklere å dele kode, og de offentlige depotene som er målrettet mot Node.js vokser raskt. Mens PHP-publikummet kan lede på dette tidspunktet, kan fremtiden favorisere Node.js. I tillegg viser de etablerte selskapene seg ofte sprøe i møte med skiftende trender. Hvert forsøk på å modernisere en forankret plattform som Drupal med en ny versjon betyr at mange flere utviklere kan la øynene vandre mot de nyere, mer kvikke plattformene bygget rundt Node.js.
Vinklet er friskt
Det er ikke akkurat rettferdig å sammenligne "A" i "MEAN" med noe i LAMP-stakken fordi LAMP ikke inkluderer en analog. Hvis du vil gjøre noe på klientsiden, er du alene. Visst, det er mange gode PHP-baserte rammer som fungerer med MySQL, men hver er litt annerledes og beveger seg i sin egen retning. WordPress, Joomla og Drupal, for eksempel, tilbyr forskjellige strategier, og det er vanskelig å bytte mellom dem, enn si portkode fra den ene til den andre. Å salve en klientramme gir konsistens og stabilitet.
Det hjelper også at Angular ble bygget av folk med 20 års erfaring med å bygge webapper. De visste godt nok til å overlate designarbeidet til HTML og CSS. De fant også ut hvordan du legger til litt JavaScript for å skanne HTML. Designerne av Angular så på hva mennesker gjør bra, og skreddersydd deretter JavaScript for å støtte menneskene. Templatesystemet og de logiske lagene er dramatisk renere enn det vi har sett før, delvis fordi teamet fant ut enklere måter å utnytte den lokale kraften i JavaScript til å gjette hva du gjør.
Mix og match
Selvfølgelig, hvis du er veldig kresen, er det ingen grunn til at du ikke kan blande det litt sammen. Mange utviklere bruker MongoDB med Apache og PHP, og andre foretrekker å bruke MySQL med Node.js. Angular fungerer ganske bra med enhver server, til og med en som kjører PHP for å levere data fra MySQL. Du trenger ikke å være en slave av akronymer.
