Cateva intrebari despre MEAN?

Recent am zis sa pun mana sa fac o mica aplicatie cu acest MEAN Stack. Am facut ceva REST API cu Express si Mongo DB si am zis sa incep sa vad cum rezolv cu angular insa am realizat ca nu inteleg ceva chestii. Mai exact cum fac legatura dintre backend si frontend in cazul angular (v4).

Am cautat ceva pe net dar lumea in general vorbeste de lucruri care nu ma privesc inca (webpack, cors, etc.). Din ce am inteles pana acum trebuie folosit modulul HTTP din angular pentru a prelua datele de la backend. Ce nu inteleg:

In momentul cand aplicatia e gata pentru “production” serverul creat cu node si express poate rula pe aceeasi masina cu cel creat de angular?
Este necesar sa folosesc CORS? Dar daca vreau ca un alt frontend (aplicatie smartphone de exemplu) sa foloseasca acelasi API trebuie folosit acest CORS?
Cat de important este webpack?

Daca aveti sfaturi de genul best practices sunt interesat :slight_smile:

Structura aplicatiei este ceva de genul:

ProjectApp: - server.js
- routes
- views: - index.html
- client (angular app)

Cat de corecta este treaba de mai sus? Mai am nevoie de acel views folder?

Am vazut ceva tutorial pe youtube cu angular (v2) si asta era structura insa in momentul in care se facea legatura intre angular si express in server.js era setat ca static folderul client si in views era pus fisierul index.html care venea cu angular insa am incercat dar app.component nu se incarca. Sper ca m-am facut inteles cat de cat…

1 Like

Da. Express poate servi si resurse statice (daca sunt probleme de performanta poti incerca un server web/proxy gen nginx pentru resursele statice cu serverul de API ruland pe alt port).

Recomand sa “rezervi” un namespace in URL pentru accesul la api gen /api care se va referi doar la rutele dinamice.

Pentru aplicatie mobila nativa nu.
Daca e o aplicatie care se incarca in webview atunci s-ar putea sa ai nevoie cu conditia ca api + angular sa vina de pe domenii diferite (nu cred ca e cazul tau).

Ar trebui sa te ajute in development, cu deploy-ul si refresh-ul de assets-uri combinat cu un live reload sa poti testa cat mai rapid modificarile.

O sa primesti zeci de variante pentru asta sunt diferite moduri sa organizezi codul.
Personal folosesc un folder /public pe radacina unde se copiaza/proceseaza resursele statice si acela va fi radacina site-ului web static, views + controller sub acelasi folder ca un tot unitar (componenta).

public/index.html
public/js/app.js + source map
public/css/app.css + source map
client/ - aici intra codul angular
server/ - aici intra codul de server

2 Likes

Lucruri care nu te privesc încă ? Webpack e destul de important și acum au și o documentație decentă, cors e critic. Poți încerca să folosești fuse-box în loc de webpack dacă nu te interesează tree-shaking-ul.

Angular este gandit pentru Single Page Applications, similar cu React, Vue etc. Drept urmare lucrurile sunt o idee diferite si mai complexe decat intr-o aplicatie web “standard”.

In productie, codul js este asamblat intr-unul sau mai multe bundle-uri de JS minificat, ce contin codul aplicatiei, Angular, alte librarii etc. E vorba despre un fisier static, asa ca trebuie servit ca atare. Express poate servii aceste resurse, sau le poti pune pe un CDN. Serverul din angular este pentru development, si, probabil, are o groaza de feature-uri precum hot code realoading, incarcare de fisiere separata etc. Asa ca nu ar trebui folosit in productie. Procesul de build si deployment pe care il pui la cale ar trebui sa se ocupe de aducerea codului din repository-ul tau intr-o forma buna pentru serving-time.

CORS e necesar cand ai requesturi cross-origin in browser, pornite “programatic” - ajax & fetch in principiu. E o idee buna sa ai in principiu pentru ca are si rol de whitelist, cel putin pentru clientii well-behaved.

Webpack nu e chiar cea mai intuitiva bucata de tehnologie, dar aceasta carte e un overview bun pentru el. Poti face multe numai cu webpack, si cu siguranta pentru aplicatii mai mici/medii/maricele e OK. Cand incepe sa-si arate limitele, poti folosi si gulp impreuna cu el. Dar am gasit ca pot face majoritatea lucrurilor din webpack, si e preferabil sa fie un proces de build mai simplu. E greu de evitat tooling de genul asta totusi pentru modern webdev.

O chestie pe care o folosesc este sa am doua sau mai multe proiecte pentru aplicatii SPA. Un proiect/repository este front-end-ul, ca aplicatie SPA plus o mica infrastructura de static-serving, server-side rendering etc. Alt/e proiect/e este un server ptr un API REST-ish pentru problem domain. Toolingul pentru back-end e mult mai simplu pentru cel de frontend. Conceptual nu prea are sens sa le pui pe ambele intr-o singura aplicatie, si e mai mult o ramasita din aplicatiile web standard. Un viitor client mobil, sau alte aplicatii interne vorbesc cu API-ul independent de front-end-ul utilizatorilor, de exemplu.

2 Likes

Ok, ok, trebuie s-o zic:

După ce stai toată ziua să configurezi pachete/unelte, îți mai rămân 10 minute să scrii cod efectiv :smiley:

Dezvoltare modernă©

5 Likes

Asa se intampla intotdeauna cand folosesti o tehnologie noua (pentru tine), este necesara o perioada de invatare/adaptare.
Daca stai o zi sa configurezi pachete/unelte, incepand cu a doua zi poti sa scrii cod 8h :).

Dupa ce ai folosit o tehnologie ani la rand, ti se poate parea banal sa configurezi un proiect in acea tehnologie. Poate ai uitat dupa acest timp, dar sigur si tie ti-a luat multe ore la inceput pana ai putut sa scrii cod efectiv.

Apoi mai depinde si de tehnologie. Una e cand folosesti HTML/CSS/ES5, si cu totul altceva cand folosesti Angular/React/Vue(html templates)/LESS/SASS/ES6+/TypeScript. In ultimul caz ai nevoie de unelte, asta e situatia.

2 Likes

Dap, eu întotdeauna am început să scriu cod în primele 10 minute. Orice altceva e doar o piedică productivității. Și, da, dezvoltare înseamnă să măsori de 10 ori și să tai o dată, dar prea se exagerează cu uneltele adiționale.

Am făcut proiecte și în Angular 1.X și din nou, scrisul de cod a fost activitatea care a apărut în prima jumătate de oră.

1 Like