Programmering

MEAN vs. LAMP til dit næste programmeringsprojekt

Overgangen fra banebrydende nysgerrighed til praktisk arbejdshest er ikke en, som mange teknologier skaber. Gårsdagens for tidlige oprør kan ofte ikke leve op til deres version 0.1-løfte. Ikke så for de teknologier, der udgør den voldsomt forkortede MEAN-stak.

Det var kun for få år siden, at MongoDB, Express.js, AngularJS og Node.js hævede øjenbrynene alene. Nu er de vokset op og flokket sammen, og sammen laver de seriøst arbejde og krypskytter ikke et lille antal udviklere fra den store LAMP-lejr. Men hvordan præcist stammer denne nyfødte MEAN-ting op mod LAMP? Hvornår er det bedre at vælge den velprøvede, modne LAMP frem for denne upstart-samling af JavaScript-centrerede teknologier?

Svaret er, når enkelheden og den fælles struktur gør dit liv lettere. MongoDB tilbyder et mere fleksibelt, imødekommende lag til lagring af data. Node.js giver en bedre nexus til at køre din server, mens Express hjælper med at standardisere, hvordan du bygger dine websteder. På klienten giver Angular en ren måde at tilføje interaktive funktioner og AJAX-drevne rige komponenter på. Sæt dem alle sammen, og de laver en ren, sammenhængende mekanisme til at flytte data fra bruger til diskfarm og tilbage igen.

Den virkelige forklaring er dog dybere. Her tilbyder vi ni grunde til at give MEAN et skud med dit næste projekt. Ikke alle har tid eller budget til at kaste ud og genkode det gamle i de nyeste, mest trendy rammer, og du skal heller ikke smide den solide pålidelighed af kamptestede værktøjer som Apache, MySQL eller PHP. Men for grønne feltprojekter, der kan drage fordel af fleksibilitet, enkelhed og ydeevne, kan det at gøre MEAN gøre dit liv bedre, end du tror.

MongoDB er bygget til skyen

Hvis din webapps planer inkluderer at gøre godt på skyenes øre pr. CPU-løfte, tilbyder MEAN-stakken et overbevisende databaselag i MongoDB. Denne moderne database er udstyret med automatisk afskærmning og fuld klyngesupport lige uden for kassen. Tilslut MongoDB, og det spreder sig over din klynge af servere for at tilbyde failover-support og automatisk replikering. I betragtning af den lethed, hvormed apps kan udvikles, testes og hostes i skyen, er der ringe grund til ikke at overveje MongoDB til dit næste projekt.

MySQLs struktur er begrænsende

Enhver, der har udviklet eller vedligeholdt en LAMP-baseret app i nogen tid, ved, at MySQLs styrke som en relationsdatabase til tider kan føles lidt fængslende. Som alle relationsdatabaser tvinger MySQL dig til at skubbe dine data ind i tabeller. Dette er ikke et problem, hvis hver enkelt post passer i nøjagtig det samme format, men hvor ofte er verden så generøs? Hvad hvis to personer deler den samme adresse, men ikke den samme konto? Hvad hvis du vil have tre linjer til adressen i stedet for to? Hvem har ikke forsøgt at rette en relationsdatabase ved at skore for meget data i en enkelt kolonne? Ellers tilføjer du endnu en kolonne, og tabellen bliver ubegrænset.

MongoDB tilbyder derimod en dokumentstruktur, der er langt mere fleksibel. Vil du tilføje en ny smule personlige oplysninger til dine brugerprofiler? Føj blot feltet til din formular, rul det op med resten af ​​dataene i et JSON-dokument, og skub det ind i din MongoDB-samling. Dette er fantastisk til projekter i flux og til at håndtere data, der i sidste ende kan være vanskelige at begrænse i tabelform.

Diskplads er billig

Blandt de store åbenbaringer af relationsdatabaser var JOIN-kommandoen. Med JOIN kunne vi spare diskplads ved at fjerne gentagne felter som by, stat og postnummer. Ved at gemme disse ofte tilgængelige og gentagne data i separate tabeller, der kan medtages i fremtidige resultater via en JOIN, holder vi vores database pæn og vores diske slanke.

Men JOIN'er kan være vanskelige for nogle og hårde på RAM, og selvom det stadig er en god ide at isolere og få adgang til data i separate tabeller gennem JOIN'er, er der ikke så meget behov for at spare diskplads nu, når diskdrev måles i flere terabyte. Rummet er så billigt, at nogle databasedesignere ender med at denormalisere deres data, fordi JOIN'erne er for langsomme. Når du har gjort det, behøver du ikke en relationsdatabase så meget. Hvorfor ikke bruge MongoDB i stedet?

Node.js forenkler serverlaget

Navigering i de forskellige lag i LAMP-stakken kan være en vanskelig dans af mange hatte, en der får dig til at blande gennem forskellige konfigurationsfiler med forskellig syntaks. MEAN forenkler dette ved brug af Node.js.

Vil du ændre, hvordan din app ruter anmodninger? Drys lidt JavaScript i, og lad Node.js gøre resten. Vil du ændre den logik, der bruges til at besvare forespørgsler? Brug også JavaScript der. Hvis du vil omskrive webadresser eller konstruere en ulige kortlægning, er det også i JavaScript. MEAN-stakens afhængighed af Node.js placerer denne form for rørledning alt på ét sted, alt sammen på et sprog, alt sammen i en bunke med logik. Du behøver ikke at genlæse mandsiderne for PHP, Apache og hvad du ellers føjer til stakken. Mens LAMP-generationen har forskellige konfigurationsfiler til alt, undgår Node.js dette problem helt. At have alt i et lag betyder mindre forvirring og mindre chance for mærkelige bugs skabt af underlige interaktioner mellem flere lag.

MEAN gør kode isomorf

Enkelheden stopper ikke med at bruge JavaScript på serveren. Ved at gå MEAN kan du også nyde den samme JavaScript på klienten og efterlade LAMP stack's klient / server skizofreni. Hvis du skriver kode til Node og beslutter, at den er bedre placeret i Angular, kan du let flytte den over, og det er næsten sikkert at køre på samme måde. Denne fleksibilitet gør programmering af MEAN-baserede apps betydeligt lettere. Plus, hvis du bemander et projekt, behøver du ikke kigge efter en PHP-ekspert og en JavaScript-ekspert eller en front-end og en back-end-specialist. I stedet er det hele JavaScript på tværs af stakken.

JSON overalt

Angular og MongoDB taler begge JSON, ligesom Node.js og Express. Dataene flyder pænt blandt alle lagene uden omskrivning eller omformatering. MySQLs oprindelige format til besvarelse af forespørgsler er godt det helt eget. Ja, PHP har allerede koden til at importere MySQL-data og gøre det let at behandle i PHP, men det hjælper ikke klientlaget. Dette kan være lidt mindre over for erfarne LAMP-veteraner, fordi der er så mange velafprøvede biblioteker, der nemt konverterer dataene, men det hele virker lidt ineffektivt og forvirrende. MEAN bruger det samme JSON-format til data overalt, hvilket gør det enklere og sparer tid på omformatering, når det passerer gennem hvert lag. Derudover gør JSONs allestedsnærværelse gennem MEAN-stakken det meget lettere at arbejde med eksterne API'er: FÅ, manipulere, præsentere, POST og gemme alt i ét format.

Node.js er superhurtig

Apache var fantastisk, men i disse dage er Node.js ofte hurtigere. En række benchmarks viser, at Node.js tilbyder bedre ydeevne, mens de gør meget mere. Måske er det kodens alder. Måske er Node.js hændelsesdrevne arkitektur hurtigere. Det betyder ikke noget. I disse dage, især blandt utålmodige brugere af mobilenheder, er det vigtigt at barbere endda millisekunder fra din apps ydeevne, og Node.js kan gøre det, samtidig med at det tilbyder en komplet Turing-mekanisme til omprogrammering af den.

Dybde betyder noget

PHP-elskere holder fast ved de store kodebiblioteker, der blev bygget til dominerende platforme som WordPress eller Drupal. De har gode grunde til at være stolte, men deres fordele fordamper, når Node.js indhenter.

Node.js pakkehåndtering, NPM, gør det endnu nemmere at dele kode, og de offentlige arkiver, der er målrettet mod Node.js, vokser hurtigt. Mens PHP-mængden kan føre på dette tidspunkt, kan fremtiden muligvis give Node.js. Plus, de etablerede operatører viser sig ofte at være skøre i lyset af skiftende tendenser. Hvert forsøg på at modernisere en forankret platform som Drupal med en ny version betyder, at mange flere udviklere muligvis lader deres øjne vandre mod de nyere, mere smidige platforme bygget omkring Node.js.

Vinklet er frisk

Det er ikke ligefrem fair at sammenligne "A" i "MEAN" med noget i LAMP-stakken, fordi LAMP ikke inkluderer en analog. Hvis du vil gøre noget på klientsiden, er du alene. Sikker på, der er masser af gode PHP-baserede rammer, der fungerer med MySQL, men hver er lidt anderledes og bevæger sig i sin egen retning. WordPress, Joomla og Drupal tilbyder for eksempel forskellige strategier, og det er svært at skifte mellem dem, endsige portkode fra den ene til den anden. At salve en klientramme tilføjer konsistens og stabilitet.

Det hjælper også, at Angular blev bygget af folk med 20 års erfaring med at opbygge webapps. De vidste godt nok til at overlade designarbejdet til HTML og CSS. De fandt også ud af, hvordan man tilføj lidt JavaScript til at scanne HTML. Designerne af Angular så på, hvad mennesker klarer sig godt, og skræddersyede derefter JavaScript til at støtte mennesker. Templatesystemet og de logiske lag er dramatisk renere end det, vi har set før, delvis fordi teamet fandt ud af enklere måder at udnytte den lokale magt i JavaScript til at gætte, hvad du laver.

Mix og match

Selvfølgelig, hvis du er virkelig kræsen, er der ingen grund til, at du ikke kan blande det lidt sammen. Masser af udviklere bruger MongoDB med Apache og PHP, og andre foretrækker at bruge MySQL med Node.js. Angular fungerer ret godt med enhver server, endda en der kører PHP til at levere data fra MySQL. Du behøver ikke at være en slave af akronymerne.