Node.js

Introducció a les aplicacions web

  

1. Tipus d’aplicacions

Quan estem utilitzant un ordinador, una tauleta o un telèfon mòbil, quins tipus d’aplicacions o programes podem estar utilitzant? Bàsicament distingim dos grans grups:

• Aplicacions sense connexió a Internet. Este tipus d’aplicacions no necessiten cap connexió a Internet o a una xarxa local d’ordinadors per a funcionar. Solen dir-se aplicacions d’escriptori, i podem trobar exemples molt variats: un processador de textos, un lector de llibres electrònics, un reproductor de música o vídeo, i fins i tot videojocs que tinguem instal·lats.

• Aplicacions amb connexió a Internet. Estes aplicacions sí que necessiten connexió, ja siga a Internet o a una xarxa local. Dins d’este grup, trobem diversos subtipus:

  • Aplicacions P2P (peer-to-peer): tots els elements connectats a la xarxa tenen el mateix “rang” i compartixen informació entre ells. És el mecanisme en el qual es basen diversos programes de descàrrega, com els d’arxius tipus *torrent.
  • Aplicacions client-servidor: consistixen en el fet que un conjunt d’ordinadors (anomenats clients) es connecten a un central (anomenat servidor), que proporciona la informació i els servicis sol·licitats. És el cas dels videojocs en línia, on l’ordinador del jugador (client) es connecta a un servidor central que gestiona el joc. Dins de les aplicacions client-servidor, hi ha un subtipus especialment nombrós, les aplicacions web. És en este subtipus en el qual ens centrarem.

1.1. Què és una aplicació web?

Podem trobar diverses definicions d’aplicació web buscant en Internet. Una de les més habituals fa referència a aplicacions que es carreguen o executen des d’un navegador web, accedint a un servidor. Estes aplicacions interactuen amb el servidor per a processar dades i presentar informació a l’usuari a través del navegador.

No obstant això, l’avanç experimentat en este sector durant els últims anys ha ampliat este concepte. Així, una aplicació web seria aquella realitzada a partir de llenguatges i tecnologies de desenvolupament web, com ara HTML, CSS, JavaScript, PHP, entre altres. Estes aplicacions poden executar-se en un navegador convencional o mitjançant un motor de navegador embegut en un altre sistema, com el webview d’Android o iOS.

• Webview és un component que permet a les aplicacions mostrar contingut web sense haver d’obrir un navegador. Encara que té un ús més limitat que un navegador, esta dissenyat per a consultes puntuals des de la pròpia aplicació, la qual cosa permet una càrrega de pàgines més ràpida. Aplicacions com Facebook i Instagram utilitzen este component per a integrar contingut web de manera eficient.

D’esta manera, a més de les aplicacions web “tradicionals”, també tindrien cabuda en esta definició les anomenades aplicacions híbrides (desenvolupades amb tecnologies web però exportades a format natiu per a diversos dispositius), i aplicacions d’escriptori que empren tecnologies web, com el framework Electron de JavaScript. Un exemple d’estes aplicacions és Visual Studio Code, que aprofita els avantatges de les tecnologies web per a oferir experiències d’usuari avançades i multiplataforma.

2. Arquitectura d’una aplicació web

2.1. Què és “la web”?

La web és una plataforma global que proporciona accés a una gran quantitat de recursos com a documents, videojocs, xarxes socials, fòrums, entre altres. Es va popularitzar a principis dels anys 90 gràcies a aplicacions com el correu electrònic i els xats. Amb l’arribada de la web 2.0, van sorgir noves aplicacions que la van potenciar encara més, com els blogs o les xarxes socials. Hui dia, és comú veure vídeos o pel·lícules en Internet, alguna cosa que fa uns anys era impensable.

2.2. Elements d’una aplicació web

En una aplicació web podem distingir els següents tres elements principals:

• Front-end:
  • És la part de l’aplicació que s’executa en el client.
  • Els usuaris interactuen amb l’aplicació utilitzant normalment un navegador web (Google Chrome, Firefox, etc).
  • Se centra en l’experiència de l’usuari i la presentació. S’encarrega de renderitzar la interfície d’usuari, gestionar la interacció de l’usuari i enviar peticions al servidor.
  • Les tecnologies que s’utilitzen són principalment HTML, CSS i JavaScript.
• Back-end:
  • És la part de l’aplicació que s’executa en el servidor.
  • És responsable de gestionar les peticions que arriben des dels clients, processar la lògica de negoci, interactuar amb la base de dades i retornar les respostes adequades.
  • Les tecnologies utilitzades són variades:
    • Servidors web: Apatxe, Nginx, entre altres.
    • Llenguatges de programació: JavaScript (Node.js), PHP, Python (Django, Flask), etc.
    • Bases de dades: MySQL, PostgreSQL, MongoDB, Redis, etc.
• Comunicació entre client i servidor:
  • Assegura que client i servidor puguen interactuar de manera eficient.
  • Per a això, es definix algun protocol de comunicació perquè totes dues parts intercanvien informació. Pot ser una API REST on s’envie la informació en format JSON o algun altre protocol on s’intercanvie informació en XML o protocols simples que envien contingut HTML.

2.3. Funcionament d’una aplicació web

Com hem comentat, les aplicacions web funcionen sota una arquitectura client-servidor, que distribuïx les tasques entre els servidors (proveïdors de recursos i servicis) i els clients (sol·licitants d’estos recursos i servicis).

Els passos típics en la comunicació client-servidor són els següents:

1. El client inicia sessió en el servidor
2. El client sol·licita al servidor el recurs o servici (una pàgina web, un document, pujar informació, etc.)
3. El servidor rep la petició, la processa i determina quin programa ha d’atendre-la, enviant la petició a este programa.
4. El programa responsable processa la petició, prepara la resposta i el lliurament al servidor.
5. El servidor envia la resposta al client
6. El client pot realitzar una nova petició (tornar al pas 2) o acabar la sessió.

En molts casos, l’arquitectura del servidor és multicapa o multinivell. Això significa que podem tindre diferents aplicacions en diferents equips (o en el mateix) que oferixen recursos o servicis. Per exemple, un servidor de bases de dades pot estar en una màquina, un servidor web en una altra (o en la mateixa que el servidor de bases de dades), i un servidor de correu electrònic en una altra màquina. D’esta manera, es distribuïxen els processos i el treball, i fins i tot es podrien configurar opcions de seguretat i rendiment separades per a cada servidor.

Exemple: arquitectura de dos o tres nivells

Considerem una petició d’un client per a obtindre un llistat de notícies emmagatzemades en una base de dades. Este procés pot ser representat amb un diagrama de seqüència com seguix:

1. El client envia una sol·licitud per a iniciar sessió al servidor web.
2. Després d’iniciar sessió, el client sol·licita un llistat de dades al servidor web.
3. El servidor web processa la petició, la qual cosa pot implicar realitzar algun tipus de lògica o validació abans d’enviar la sol·licitud al servidor de base de dades.
4. Una vegada processada la petició, el servidor web envia una sol·licitud de llistat al servidor de base de dades.
5. El servidor de base de dades processa la sol·licitud i retorna el llistat de dades sol·licitades al servidor web.
6. El servidor web prepara la resposta i l’envia al client.
7. Finalment, el client envia una sol·licitud per a acabar la sessió al servidor web

En una arquitectura de tres nivells, el servidor web i el servidor de bases de dades poden estar en la mateixa màquina o en màquines separades, cadascuna amb el seu maquinari i control d’accés específics. Esta configuració és comuna en aplicacions web, ja que permeten una millor gestió i seguretat de les dades.

En una arquitectura de dos nivells, el servidor web també actua com a servidor de bases de dades, responent directament a les peticions del client sense consultar a altres servidors. Esta configuració és menys flexible i segura, i pot oferir un rendiment inferior en sistemes molt congestionats.

2.4. Localització i accés a aplicacions web

Hem vist l’arquitectura d’una aplicació web i com els elements del front-end i el back-end interactuen mitjançant la comunicació client-servidor. En este apartat veurem com es localitzen i accedixen a estes aplicacions web en Internet. Ací és on entren en joc els conceptes de dominis i URLs.

Hostings y noms de domini

El servidor, que s’encarrega de rebre peticions de tots els clients que es connecten a ell i enviar-los la informació que sol·liciten, necessita estar disponible des de qualsevol lloc en Internet perquè els usuaris puguen connectar-se a ell.

Per tant, en primer lloc, hem de buscar un servidor en Internet en el qual allotjar el nostre lloc web. Això pot fer-se de diverses formes:

• Servidor propi: disposar d’un servidor (o servidors) propis i una adreça IP pública fixa a la qual accedir. Esta opció és menys comuna hui dia a causa dels costos i la complexitat.
• Empresa d’allotjament o hosting: contractar un espai (o màquina sencera, si el projecte és gran i es disposa de pressupost suficient) en una empresa d’allotjament. Esta opció és molt més habitual, i d’aquí ve que proliferen les empreses que es dediquen al hosting com OVH, Hostinger, Ionos, etc.

A més d’un espai d’allotjament, és necessari adquirir un nom de domini perquè els usuaris puguen recordar i utilitzar per a identificar la nostra web de manera única en Internet. Este domini es vincula a l’adreça IP del servidor, permetent que les sol·licituds del client arriben al lloc correcte.

Per exemple, quan escrivim l’adreça www.google.es, un sistema conegut com DNS (Sistema de Noms de Domini) traduïx este nom de domini a l’adreça IP del servidor on està allotjada l’aplicació de Google en espanyol. Este procés, anomenat resolució de DNS, és crucial per al funcionament de les aplicacions web, ja que facilita la localització de recursos en la xarxa global.

El nom de domini s’adquirix a través del registre de domini, un procés gestionat per empreses autoritzades per la ICANN (Internet Corporation for Assigned Names and Numbers). Per a registrar un domini, s’ha de contactar amb una empresa registradora, comprovar que el domini desitjat està disponible, i seguir el procés de registre.

URLs

Hem vist que, en l’esquema de funcionament d’una aplicació web, el client sol·licita recursos al servidor. La forma en què els sol·licita és mitjançant URLs. Una URL (Uniform Resource Locator) és una seqüència de caràcters que segueix un estàndard i que permet denominar recursos dins d’Internet perquè puguen ser localitzats.

Per exemple, quan escrivim en un navegador una adreça com http://www.miweb.com/paginas/pagina.html, estem introduint una URL per a localitzar un recurs (en aquest cas, una pàgina HTML).

Una URL es compon de:

protocol://subdomini.domini.com/carpeta/pagina?param=valor

• El protocol, definix les regles per a la comunicació entre client i servidor. En una URL, el protocol va al principi, fins als dos punts i el delimitador //. En el nostre exemple, el protocol seria http (HiperText Transfer Protocol). Veurem més endavant alguns exemples de protocols.
• El nom de domini, identifica el servidor i l’entitat (empresa o web) a la qual es connectarà. Va just darrere del protocol, fins a la següent barra. Normalment acaba en .com, .és, .net, etc. En el nostre exemple seria www.miweb.com.
• El subdomini, que és opcional, és una manera de tindre un lloc web relacionat, com a annex, a una web principal. És habitual que les empreses de hosting permeten registrar subdominis, encara que algunes ho oferisquen amb unes certes restriccions, ja siga pel nombre de subdominis permesos o pel servici que presten. Per exemple, si tenim el domini www.miweb.com de l’exemple anterior com a URL principal, podríem tindre a més, tienda.miweb.com com a subdomini per a una botiga associada a la web.
• La ruta cap al recurs, que comprén totes les carpetes i subcarpetes (si n’hi ha) i el nom d’arxiu que volem obtindre. En el nostre exemple, la ruta seria /pàgines/pàgina.HTML
• Uns paràmetres opcionals, que proporcionen informació addicional a la sol·licitud, útil per al servidor en el lliurament de continguts dinàmics.

Exercici 1:

Hem vist que la ICANN autoritza diverses empreses per a gestionar el registre de noms de domini en Internet. Estes empreses, conegudes com a agents registradors de domini, oferixen diferents plans de pagament per a este servici. Cerca en Internet una llista d’agents registradors de domini oficials per a Espanya i consulta els preus que tenen alguns d’ells.

3. Protocols més utilitzats

Perquè els clients i servidors puguen comunicar-se, és necessari establir un protocol de comunicació. Un protocol definix una sèrie de regles que especifiquen quin tipus de missatges s’intercanviaran, en quina orde i quin contingut tindrà cada tipus de missatge, assegurant que tots dos extrems de la comunicació (client i servidor) puguen entendre’s.

Totes les comunicacions en una xarxa (o en Internet) es basen en el protocol TCP/IP per a funcionar. Este protocol està basat en dos parts:

• Protocol TCP, que establix com ha d’estructurar-se i fraccionar-se la informació per a ser enviada
• Protocol IP, que definix com s’identifiquen els equips en la xarxa, mitjançant adreces IP.

Sobre la base de TCP/IP, s’establixen diversos protocols específics segons el tipus d’aplicació que es vaja a utilitzar (web, correu electrònic, pujada d’arxius, etc). Per a les aplicacions web, els protocols de comunicació més utilitzats són:

• HTTP (HyperText Transfer Protocol): protocol existent des de 1990 que permet la transferència d’arxius, principalment d’arxius HTML. Funciona mitjançant un esquema de peticions i respostes entre client i servidor, com el vist anteriorment.
• HTTPS: versió segura del protocol anterior, on les dades de les peticions i les respostes s’envien encriptats, perquè ningú que intercepte la comunicació puga descrifrar el contingut d’esta. Este tipus de protocols se sol utilitzar en sistemes bancaris, plataformes de pagament (Paypal, per exemple), i altres aplicacions que manegen informació delicada (DNIs, nombres de targetes de crèdit, etc.).

Normalment, els navegadors web canvien automàticament del protocol HTTP a HTTPS en connectar amb pàgines que necessiten ser més segures (login, dades de pagament, etc.). Este canvi pot observar-se en la barra d’adreces del navegador, on es mostrarà el protocol https o la icona d’un cadenat. No obstant això, és necessari configurar el servidor web per a acceptar comunicacions HTTPS quan siga necessari.

Altres protocols, encara que menys utilitzats en aplicacions web, són essencials per a altres aplicacions en Internet. Per exemple, per a l’enviament i recepció de correu electrònic s’empren els protocols SMTP i POP3/IMAP respectivament. Per a transferir arxius a un servidor remot, es pot usar el protocol FTP. Este últim protocol és especialment útil durant el desenvolupament d’aplicacions web per a pujar actualitzacions al servidor.

3.1. Més sobre HTTP/HTTPS

El protocol fonamental per a les aplicacions web és HTTP (o la seua versió segura, HTTPS). En tots dos casos, es tracta d’un protocol per a aplicacions client-servidor, on les dades que s’envien l’un i l’altre tenen un format determinat.

Peticions HTTP

D’una banda, estan les dades que el client envia al servidor, i que es denominen peticions (en anglés, requests). Estes peticions es componen, a grans trets, de:

• La URL del recurs sol·licitat
• Unes capçaleres de petició que donen informació sobre el recurs sol·licitat i el client que el sol·licita. Per exemple, podem saber el navegador que s’està utilitzant en el client, l’idioma, etc.
• Unes dades addicionals, en cas que siguen necessaris. Per exemple, la informació introduïda en un formulari o els bytes d’un arxiu a pujar.

Totes estes dades, a baix nivell, s’encapsulen en paquets i es fragmenten d’acord amb el protocol TCP per a ser enviats al servidor.

Respostes HTTP

Per part seua, el servidor, quan rep una petició d’un client, emet una resposta (en anglés, response) amb la informació sol·licitada, o amb algun codi d’error en cas que haguera succeït algun. Les respostes es componen d’estos elements:

• Un codi d’estat, que indica si s’ha pogut atendre correctament la petició o no. Estos codis estan agrupats en categories, de manera que, per exemple:
  • Els codis 2xx indiquen una resposta satisfactòria. El normal és rebre un codi 200 si tot ha anat bé
  • Els codis 3xx indiquen que hi ha hagut algun tipus de redirecció: el recurs sol·licitat estava en una altra URL i se’ns ha redirigit a ella
  • Els codis 4xx indiquen un error per part del client. Per exemple, l’error 404 és molt típic, i indica que la URL indicada no existix. L’error 403 és també típic, i indica que el client no té permís per a accedir al recurs sol·licitat.
  • Els codis 5xx indiquen un error per part del servidor. Per exemple, que estiga col·lapsat i excedisca el temps d’espera per a atendre la petició.
• Unes capçaleres de resposta, que donen informació sobre la resposta que s’envia. Per exemple, la grandària de la resposta, el tipus de contingut (si és un document web, un arxiu ZIP, etc… és el que es coneix com a tipus MIME), l’última data de modificació, etc.
• El contingut sol·licitat, si no hi ha hagut error en tramitar la petició. Per exemple, el contingut de la web que s’ha sol·licitat, o d’un arxiu que s’ha demanat descarregar.

Monitoratge amb Google Chrome

Podem usar el navegador Google Chrome per a comprovar el que client (navegador) i servidor s’envien en un procés HTTP. Per a això, anem al menú d’Eines per a desenvolupadors, i més concretament a la secció Network. Des d’ací, accedim a una web coneguda (per exemple, ceice.gva.es), i podem comprovar la informació enviada i rebuda:

Exercici 2:

Utilitza Google Chrome (opció de Eines per a desenvolupadors, pestanya Network) per a veure l’esquema de petició i resposta HTTP cap a alguna web coneguda, com per exemple stackoverflow.com. Identifica el codi d’estat, les capçaleres de resposta (tracta d’identificar algunes d’elles) i el contingut.

4. Sistema de noms de domini o DNS

En les comunicacions en xarxes TCP/IP, quan un equip envia un paquet de dades a un altre, és necessari identificar tant l’origen com la destinació. Les aplicacions que inicien la transmissió han d’incorporar valors obligatoris com ara: adreça MAC d’origen i de destinació, adreça IP d’origen i de destinació i port d’origen i de destinació. Estos camps sempre han de tindre un valor assignat. Això significa que, quan es vol visitar una pàgina web que està allotjada en un equip (per exemple, l’equip amb el nom www.google.es), el client ha de saber quina és l’adreça IP de destinació per a incorporar-la en el paquet.

De fet, quan s’obri un navegador web és possible accedir a un recurs tant pel seu nom de domini com per la seua adreça IP. Seguint amb l’exemple anterior, si accedim a una finestra de terminal i executem el comando ping www.google.es, obtindrem en la primera línia la seua adreça IP. Si es col·loca eixa mateixa adreça IP en un navegador web, es pot comprovar que retorna la mateixa pàgina web d’inici. No obstant això, com a usuaris, ens resulta més fàcil dirigir-nos a un equip (host, servidor web, servidor de correu, etc.) utilitzant el seu nom de domini que recordar la seua adreça IP corresponent.

El DNS (Domain Name System) o Sistema de Noms de Domini és l’encarregat de proporcionar un mecanisme eficaç per a la traducció d’adreces IP de recursos de xarxa a noms fàcilment llegibles i memoritzables per les persones, i viceversa. A esta acció se la coneix com a resolució DNS. Per a això, utilitza una base de dades distribuïda i jeràrquica que associa adreces IP de hosts, servicis o qualsevol recurs connectat a internet o xarxa privada amb informació de divers tipus.

• Jeràrquica perquè s’organitza en una estructura de dominis, els quals es componen de subdominis, que al seu torn es poden dividir en altres subdominis i així fins a 127 nivells.
• Distribuïda perquè la informació de la base de dades no està tota en un solo servidor central, sinó que la informació es troba repartida per parts en diferents servidors DNS d’Internet.

El DNS suporta tant IPv4 com IPv6, i la informació s’emmagatzema en forma de registres de recursos, en anglés Resource Records (RR), de diferents tipus, els quals poden emmagatzemar adreces IP o un altre tipus d’informació. Esta informació s’agrupa en zones, que corresponen a un espai de noms o domini concrets i que són mantingudes pel servidor DNS autoritativo d’esta. A continuació, aprofundirem un poc més en estos i altres conceptes.

4.1. Elements integrants del DNS

El DNS s’estructura en tres components principals: espai de noms de domini, servidors de noms i *resolvers.

Espai de noms de domini

L’espai de noms de domini és una estructura jeràrquica d’arbre invertit on cada node conté registres de recursos (RR) que proporcionen informació sobre el component maquinari i programari que recolzen este domini, com per exemple, els hosts, els servidors de noms, els servidors web, els servidors de correu, etc.

Del node arrel, situat en el nivell més alt, partixen les branques que conformen les zones. Estes, al seu torn, poden contindre un o més nodes o dominis que al seu torn poden dividir-se en subdominis segons es baixa en la jerarquia.

• Cada node de l’arbre es diu domini i rep una etiqueta o nom. El nom de domini d’un node es crea mitjançant la concatenació de totes les etiquetes, començant per este node i acabant en el node arrel. Per tant, tot domini complet acaba en un punt final “.” que indica el final de l’espai en la zona arrel.
• El nivell més alt de tota la jerarquia és el domini arrel o root, i es representa per “.” (punt). En el sistema DNS un node pot tindre un nom de fins a 63 caràcters. La profunditat de nodes està limitada a 127 nivells.
• Just un nivell per davall es troben els Top Level Domains o TLDs, els quals estan allotjats en el que es coneix com a servidors arrel. Existixen diversos servidors arrel situats en diferents continents. S’identifiquen amb les lletres de l’alfabet, i diversos d’ells es troben dividits físicament i dispersos geogràficament amb la finalitat d’augmentar el seu rendiment. Els seus noms són de la forma letra.root-servers.org. Són gestionats per organitzacions independents. Per exemple, a.root-servers.org és gestionat per VeriSign, Inc. Pots trobar més informació sobre estos servidors en https://root-servers.org/.
• Respecte als TLDs, existixen 3 tipus:
  • Dominis de nivell superior geogràfics (ccTLD): són aquells TLDs que representen a països. Utilitzen els codis de país de dos lletres definits en estàndard ISO-31663. Per exemple, .és per a Espanya, .fr per a França, .pt per a Portugal, etc.
  • Dominis de nivell superior genèrics (gTLD): aquells TLD que estan oberts a qualsevol persona o organització. Estan formats per tres o més caràcters. Per exemple, .biz per a negocis, .com per a propòsits comercials, .info per a informació general, etc.
  • Dominis de nivell superior d’infraestructura (uTLD): esta categoria té un únic TLD, .arpa, que s’utilitza exclusivament per a la gestió de la infraestructura.
• Els TLDs, al seu torn, són nodes pare d’altres nivells inferiors que es coneixen com TLDs de segon nivell.
• La jerarquia continua fins a arribar a un node final que representa un recurs. Per exemple “www.miweb.com” realment és “www.miweb.com.”, on el punt final més a la dreta representa la zona arrel, encara que este últim normalment no es mostra. El nom format per tota la cadena es coneix com Fully Qualified Domain Name (FQDN).

És important no confondre els conceptes de zona i domini. Un domini es dividix en subdominis per a facilitar la seua administració, i cada part administrada per un o més servidors *DNS és una zona. El domini és l’arbre de l’espai de noms i la zona és la part de l’arbre administrada per un servidor de noms de domini concret.

En la figura anterior hi ha tants dominis com requadres de lletres agrupats en 4 zones delimitades per les línies discontínues. El nom de domini corresponent a cada zona (es nomenen segons el seu node superior) és A, B.A, C.A, I.C.A. Cadascuna d’aquestes quatre zones tindrà un o més servidors DNS per a gestionar-la.

Servidors de noms

Els servidors de noms són servidors encarregats de mantindre i proporcionar informació de l’espai de noms o dominis.

• Servidors autoritatius: emmagatzemen informació completa per a una o diverses zones de les quals són responsables. Proporcionen respostes sobre els dominis per als quals han sigut configurats. L’estàndard que definix el DNS establix que tota zona ha de tindre, almenys, dos servidors autoritatius:
  • El primari, que guarda i administra les versions definitives dels registres de recursos de la zona
  • El secundari, que guarda una còpia que s’actualitza cada vegada que es produïx un canvi, a través d’un procés conegut com a transferència de zona. Això proporciona un mecanisme de redundància, robustesa, rendiment i còpia de seguretat, ja que si el servidor primari falla, la xarxa continua operativa gràcies al servidor secundari.
• Servidors caché: emmagatzemen conjunts de registres de diferents zones obtinguts consultant als corresponents servidors autoritatius (cerques recursives). Esta informació s’emmagatzema localment de manera temporal (caché) i es renova periòdicament. Els servidors caché ajuden a descongestionar servidors que reben grans quantitats de peticions.

Amb esta organització de servidors de noms, i la seua intercomunicació, s’aconseguix la distribució i redundància de l’espai de dominis.

Resolvers

Un resolver és una rutina del sistema operatiu que funciona com a intermediària entre les aplicacions, el sistema operatiu i els servidors DNS. Quan una aplicació necessita una resolució, ja siga d’un nom o d’una adreça IP, crida a esta rutina retornant la informació desitjada de manera compatible perquè el host l’entenga.

4.2 Procés de resolució DNS

La principal funció d’un servidor DNS és respondre a consultes de clients o d’altres servidors DNS. Existixen dos tipus principals de consultes:

• Consulta recursiva:
  • El resolver (client) demana al seu servidor DNS local una resposta basada en els seus arxius de zona o caché.
  • Si el servidor no té la informació sol·licitada, respon amb el punter al servidor arrel “.”.
  • El resolver consulta al servidor arrel, després els servidors de domini de nivell superior (TLD), i així successivament, fins a trobar el servidor autoritatiu que té la resposta correcta.
  • Normalment, el resolver fa una consulta recursiva a un servidor DNS intermedi que actua com a caché recursiu, evitant que el client haja de realitzar múltiples consultes.
• Consulta Iterativa:
  • El resolver sol·licita al servidor DNS una resposta o un error si el recurs no existix.
  • El servidor DNS actua com a intermediari, realitzant consultes iteratives a altres servidors DNS fins a obtindre la resposta o un error.

Per tant, les consultes recursives són generalment generades pels clients DNS, mentres que les consultes iteratives són creades pels servidors DNS en consultar a altres servidors.

En termes generals, el procés que se seguix en una resolució DNS és el següent.

• El client (resolver) envia la consulta al seu servidor DNS.
• Si el servidor DNS té autoritat sobre el domini consultat, retorna la resposta usant els seus propis registres.
• Si el servidor no té autoritat i no és recursiu, informa al resolver on ha de dirigir la seua consulta.
• Si el servidor no és autoritatiu però és recursiu, realitza consultes iteratives per a trobar el servidor autoritatiu i retorna la resposta al client, emmagatzemant la informació en caché per a futures consultes.

Vegem un exemple concret de resolució de noms per a comprendre millor el procés. Suposem que un client necessita localitzar l’equip www.educacion.gob.es i envia una petició al seu servidor DNS. Assumim també que el seu servidor no té informació sobre eixe domini. Així, observarem com es duu a terme la resolució completa

1. Consulta inicial del client: un client, mitjançant un navegador web, sol·licita la resolució del nom de domini www.educacion.gob.es. El resolver consulta la seua caché per a veure si té l’adreça IP emmagatzemada.
2. Consulta al servidor DNS local: si l’adreça no està en la caché, el resolver envia una consulta recursiva al servidor DNS primari o local configurat. Este servidor pot estar dins de l’empresa o en Internet. El servidor DNS local revisa la seua caché i, si troba la informació, retorna l’adreça IP corresponent.
3. Consultes iteratives del servidor DNS: si el servidor DNS local no pot resoldre la consulta, inicia una sèrie de consultes iteratives per a trobar el servidor autoritatiu del domini:
   • Servidor arrel: consulta al servidor arrel. Si no és autoritatiu, el servidor arrel retorna el nom del servidor responsable del domini de primer nivell (.és).
   • Servidor TLD: consulta al servidor del TLD (.és). Si no és autoritatiu, retorna el nom del servidor responsable del domini de segon nivell (.gob.es).
   • Servidor del domini específic: consulta al servidor del domini de segon nivell (.gob.es). Si no és autoritatiu, retorna el nom del servidor responsable del domini específic (educacion.gob.es).
4. Resposta del servidor autoritatiu: finalment, s’arriba al servidor autoritatiu per al domini educacion.gob.es, que retorna l’adreça IP de www.educacion.gob.es al servidor DNS local.
5. Actualització i resposta:
   • El servidor DNS local actualitza la seua caché amb la nova informació.
   • El servidor DNS local envia la resposta al resolver del client.
   • El resolver del client actualitza la seua caché.
   • La resposta arriba al navegador web en el format adequat, completant la sol·licitud de resolució.

Este procés consumix bastant amplada de banda, per la qual cosa és recomanable implementar una solució DNS interna amb caché, especialment en xarxes amb alt trànsit cap a l’exterior, com a col·legis, universitats, biblioteques o grans empreses. Això permet obtindre temps de resposta més ràpids i una millor experiència de navegació web.

Eina DIG

DIG (Domain Information Gopher) és una eina de línia de comandes que realitza cerques en els registres DNS, a través dels noms de servidors, i mostra el resultat. Es pot executar tant en Linux com en Windows encara que, en aquest últim, és possible que siga necessària la seua instal·lació prèvia.

Vegem un exemple de com funciona amb la comanda dig www.gva.es:

Explicació de l’eixida:

• Totes les línies que inicien amb “;” són comentaris.
• La primera línia ens retorna la versió del comando dig que estem utilitzant.
• Després mostra una secció de consulta (question section) amb la nostra consulta .
• A continuació, apareix la secció de resposta (answer section) que conté la resposta del servidor DNS.
  • Esta secció pot incloure diferents tipus de registres de recurs (RR). Per defecte, la resposta està associada al registre de recurs de direcció A (RR A) i al registre de recurs de nom canònic (RR CNAME), però també es poden consultar altres registres.
  • El registre de direcció A (RR A) associa noms de domini (FQDN) a direccions IPv4. El registre A té l’estructura següent: NomDomini IN A IP.
  • El registre de recurs nom canònic (RR CNAME) enllaça el nom de domini amb un àlies, és a dir, amb un altre nom que també redirigix al mateix contingut. El verdader nom, per tant, és el que es connecta a través del registre A amb l’adreça IP. L’avantatge d’este sistema és que, si l’adreça IP canvia, només és necessari modificar el registre A. Com que tots els àlies es guien segons este registre A. La seua estructura és la següent: NomDomini IN CNAME Nom canònic o IP
• Interpretació de la resposta:
  • Primer es mostra el registre CNAME que indica que www.gva.es és un àlies de simac13.gva.es.
  • Després es mostren dos registres A per a simac13.gva.es, proporcionant les seues adreces IP.
  • Cada registre comença amb el nom complet del domini (incloent el punt final), seguit del temps en segons que romandrà el registre en la memòria caché.
• Estadístiques de la consulta:
  • Finalment, es mostren estadístiques com el temps de consulta, el servidor que va respondre, la data i hora de la consulta i la grandària del missatge rebut.

Si s’executa DIG especificant l’opció +trace, es mostra una traça dels servidors pels quals passa la consulta fins a arribar al servidor autoritatiu, permetent veure la llista completa de nodes i passos de resolució d’un nom. Això és molt útil per a entendre com funciona el sistema de noms de domini.

5. Patrons de disseny programari

Després de revisar els tipus d’aplicacions web, l’arquitectura bàsica, els protocols més comuns i el paper del *DNS, arribem a un component essencial en el desenvolupament d’aplicacions web robustes i eficients: els patrons de disseny.

Un patró de disseny o arquitectura programari comprén un conjunt de pautes a seguir, elements a desenvolupar, jerarquies i ordre que doten a una aplicació d’una estructura preestablida, que la fa més propícia per a funcionar com deu. Els seus principals objectius són, d’una banda, estandarditzar la forma en què es desenvolupen les aplicacions, i per un altre, elaborar elements o components reutilitzables entre diverses aplicacions, en ajustar-se tots a un mateix patró.

En l’àmbit de les aplicacions web, existeixen patrons de disseny específics que ens guien a l’hora d’estructurar, dissenyar i programar aquestes aplicacions. Un dels més utilitzats (o potser el més utilitzat) és el patró MVC, que comentarem a continuació, però també han sorgit uns altres (molts a partir d’aquest), que han volgut fer un volt de rosca més, o adaptar-se a les necessitats d’aplicacions web més específiques o concretes. Veurem també alguns d’aquests patrons en aquest apartat.

5.1. El patró MVC

MVC són les sigles de Model-Vista-Controlador (o en anglés, Model-View-Controller), i és, com déiem abans, el patró per excel·lència ara mateix en el món de les aplicacions web, i fins i tot moltes aplicacions d’escriptori.

Com el seu nom indica, aquest patró es basa a dividir el disseny d’una aplicació web en tres components fonamentals:

• El model, que podríem resumir com el conjunt de totes les dades o informació que maneja l’aplicació. Típicament seran variables o objectes extrets d’una base de dades o qualsevol altre sistema d’emmagatzematge, per la qual cosa el codi del model normalment estarà format per instruccions per a connectar amb la base de dades, recuperar informació d’ella i emmagatzemar-la en algunes variables o classes determinades. Per tant, no tindrà coneixement de la resta de components del sistema.
• La vista, que és l’intermediari entre l’aplicació i l’usuari, és a dir, la qual cosa l’usuari veu en pantalla de l’aplicació. Per tant, la vista la compondran les diferents pàgines, formularis, etc, que l’aplicació mostrarà a l’usuari per a interactuar amb ell.
• El controlador (o controladors), que són els fragments de codi encarregats de coordinar el funcionament general de l’aplicació. Davant peticions dels usuaris, les recullen, les identifiquen, i accedeixen al model per a actualitzar o recuperar dades, i al seu torn, decideixen quina vista mostrar-li a l’usuari a continuació de l’acció que acaba de realitzar.

És un patró de disseny molt concís i ben estructurat, la qual cosa li ha valgut la fama que té hui dia. Entre els seus molts avantatges, permet aïllar el codi dels tres elements involucrats (vista, model i controlador), de manera que el treball és molt més modular i divisible, podent encarregar-se de les vistes, per exemple, un dissenyador web que no tinga molta idea de programació en el servidor, i del controlador un programador PHP que no tinga moltes nocions d’HTML.

En forma d’esquema, podríem representar-ho així:

5.2. Altres alternatives a MVC

Com a alternatives al patró MVC, i arran d’aquest mateix patró, van sorgir uns altres una mica més específics. Quasi tots ells tenen com a base la part del model (és a dir, l’accés i gestió de les dades o informació de l’aplicació) i la part de la vista (és a dir, la presentació a l’usuari). Així, podríem dir que l’únic punt “discordant” seria el controlador, que en altres patrons s’ha substituït per altres elements. De fet, al conjunt de patrons que segueixen aquesta filosofia (és a dir, centrar-se en la vista i el model, i afegir alguna cosa més), se’ls sol cridar en general MVW (en anglés, Movel-View-Whatever, en espanyol, Model-Vista-Qualsevol cosa). La finalitat d’això és, en alguns casos, descompondre el treball realitzat pels controladors en diversos submòduls, i en altres casos, prescindir directament del controlador. Vegem alguns dels patrons més populars.

El patró MVVM

El patró MVVM, com recullen les seues sigles, se centra exclusivament en els components del model i de la vista (Model-Vista-Vista-Model), i prescindeix del controlador. D’aquesta manera, l’usuari interactua directament amb la vista, i les accions o canvis que introduïsca en ella afecten directament el model, i viceversa (els canvis en el model es reflecteixen de manera automàtica en la vista).

Aquest patró està cobrant especial rellevància en les anomenades SPA (Single Page Applications), aplicacions web amb una sola pàgina que recarrega parcialment els seus continguts davant les accions de l’usuari. En aquests casos, no és necessari un controlador que diga quina vista carregar, perquè només hi ha una vista principal (que pot estar composta per subvistas), i si l’estructura és prou senzilla, vista i model poden estar intercomunicats sense intermediaris. Alguns frameworks sorgits últimament han donat encara més pes a aquest patró, com és el cas d’Angular.

El patró MOVE

El patró MOVE substitueix el controlador del patró MVC per dos elements. Un que denomina operacions (que seria l’O de les seues sigles), i que englobaria tot el conjunt d’accions que l’aplicació és capaç de realitzar, i un altre que serien els esdeveniments (que seria l’E de les seues sigles), i que representarien tots aquells successos que desencadenen que s’execute una operació determinada. Així, les accions dels usuaris són esdeveniments sobre l’aplicació que provoquen que s’executen determinades operacions. Aquestes operacions, al seu torn, poden accedir al model per a obtindre o actualitzar informació, i poden generar o cridar a una vista que mostrar a l’usuari com a resposta. Es divideix així la tasca dels controladors entre els esdeveniments i les operacions.

El patró MVP

El patró MVP substitueix el controlador (o controladors) del MVC pel que es denominen presentadors. Aquests presentadors són una espècie d’intermediaris entre el model i la vista, de manera que cada vista té el seu propi, i actua després de la vista per a comunicar-se amb el model, obtindre les dades, i carregar-los en ella per a mostrar-los a l’usuari. Es té així encapsulat amb cada vista el seu presentador, i l’aplicació pot considerar-se un conjunt de parells vista-presentador, que s’encarreguen de comunicar-se amb el model, que queda per darrere.

6. Recursos necessaris

Per a implantar una aplicació web i que els clients puguen utilitzar-la, necessitem comptar amb una sèrie recursos maquinari i programari.

• En el costat del client, simplement caldrà comptar amb un equip amb el maquinari necessari (depenent de l’aplicació web que siga, podrà ser un mòbil, una tauleta, portàtil, PC…), i, típicament, un navegador web instal·lat (encara que també podria tractar-se d’una aplicació híbrida per a mòbil, o d’escriptori, i en aquest cas faria falta l’aplicació en si).
• En el costat del servidor, normalment necessitarem almenys un PC servidor amb un maquinari relativament potent (quant a processador, memòria RAM i capacitat de disc dur). En ell, necessitarem tindre instal·lat:
• Un servidor web, o servidor d’aplicacions, on tindrem allotjada la nostra aplicació web, i atendrà les peticions dels clients. Normalment es tindrà un servidor web localitzable en Internet on instal·lar l’aplicació web definitiva (anomenat servidor de producció), i un altre en algun ordinador local on anar-la desenvolupant i provant fins a acabar-la (servidor de proves).
• Addicionalment, si la nostra aplicació web ho requereix, un servidor de base de dades o sistema gestor de bases de dades (SGBD). Aquesta opció és molt comuna en les aplicacions web, perquè la majoria accedeixen a una certa informació que, en general, està emmagatzemada en una base de dades.

6.1. Llenguatges

En parlar d’aplicacions web, és important determinar el llenguatge o llenguatges de programació en què es desenvolupen. En l’àmbit de les aplicacions web, distingim dos tipus de llenguatges:

• Llenguatges en l’entorn client o llenguatges client: són els que permeten que el client interactue amb l’aplicació web. Per a això, el client ha de poder veure l’aplicació web en el navegador, i interactuar amb ella (punxar en enllaços, emplenar formularis, etc.). En aquest costat, normalment es parla de HTML i CSS per al disseny de les pàgines (encara que no són llenguatges de programació pròpiament dits), i de JavaScript per a poder facilitar la interacció entre l’usuari i el navegador. També existeixen uns altres frameworks i eines que faciliten o amplien les possibilitats de desenvolupament en el client, com ara SASS (un compilador CSS que permet introduir una mica de programació en els documents CSS), i molts frameworks o llibreries JavaScript, com a Angular, React, Vue… A més, existeix algun llenguatge alternatiu, com TypeScript, similar a JavaScript però amb unes característiques més restrictives i estructurades quant a l’escriptura de codi.
• Llenguatges en l’entorn servidor o llenguatges servidor: són els que permeten que el servidor faça unes certes tasques quan li arriben les peticions dels clients, com per exemple consultar una base de dades, guardar informació en un fitxer, o carregar una foto que l’usuari està pujant al servidor. En aquest altre costat, existeixen diverses famílies de llenguatges que podem triar, depenent del servidor web que vulguem utilitzar. Per exemple, podem utilitzar llenguatge ASP .NET (per a servidors de Microsoft i entorns Windows), o el llenguatge JSP (llenguatge Java per a aplicacions web), o el llenguatge PHP, entre altres. També últimament s’ha fet un lloc en aquest grup el llenguatge JavaScript, a través del framework Node.js.

6.2. Exemples de programari

Hem vist a grans trets el maquinari i programari que necessitarem tant en els clients com en el servidor. Quin programari concret utilitzarem en aquest curs?

En el cas del navegador per al client, existeixen diverses opcions depenent del sistema operatiu del client: Mozilla Firefox, Google Chrome, Internet Explorer / Edge (només per a Windows), Safari (només en Windows i Macintosh), Opera… Possiblement els dos primers (Chrome i Firefox) són les millors opcions.

En el cas del servidor web, dependrà del tipus de llenguatge servidor que anem a utilitzar per a fer la nostra pàgina, i del sistema operatiu del servidor. En el nostre cas, emprarem llenguatge PHP, i també JavaScript amb el framework Node.js. Per al primer, emprarem el servidor Apatxe, que instal·larem a través d’algun sistema XAMPP o similar, que integra Apatxe amb un servidor MySQL/MariaDB i el llenguatge PHP preinstal·lats. Per al segon, instal·larem el framework Node.js per a construir amb ell el servidor, i alguns mòduls addicionals per a facilitar la tasca del desenvolupament de l’aplicació en si, com veurem en unitats posteriors.

Si emprarem llenguatge Java (JSP, servlets, etc.), podem instal·lar algun servidor senzill i gratuït com Tomcat, o servidors d’aplicacions més pesats i complexos com Glassfish. També funcionen en tota mena de sistemes Si optem per tecnologia .NET (ASP.NET), podem utilitzar IIS (Internet Information Services), un servidor web disponible per a Windows, ja que aquesta tecnologia només funciona en sistemes operatius Windows.

Per al servidor de base de dades, podem emprar diferents alternatives, com MySQL/MariaDB, PostreSQL, Oracle, o SQL Server. També podem optar per sistemes No-SQL, com MongoDB. Totes ofereixen versions gratuïtes (algunes d’elles amb recursos limitats per a ús personal) i comercials (més potents). MySQL, PostgreSQL i Oracle funcionen en diversos sistemes, però SQL Server és propietat de Microsoft, i funciona en sistemes Windows. En el nostre cas, optarem per un servidor MySQL/MariaDB per a la comunicació amb PHP i Apatxe (a través de l’esmentat XAMPP), i per un servidor MongoDB per a les aplicacions que fem amb Node.js.

IDEs

Per al desenvolupament d’aplicacions és necessari comptar amb un bon entorn de desenvolupament o IDE amb el qual editar el codi, depurar i provar les aplicacions.

Existeixen multitud d’opcions disponibles, la majoria d’elles gratuïtes. Des d’entorns de propòsit general vàlids per a molts llenguatges (Atom, Sublim, Visual Studio Code…) a uns altres més específics i orientats a algun llenguatge en concret, com PhpStorm.

En el nostre cas, optarem per Visual Studio Code, per la seua versatilitat i popularitat creixent. Permet instal·lar multitud d’extensions per a treballar amb diferents tipus de llenguatges i frameworks, i ens permet també una fàcil integració amb PHP i Node.js.

Alguns frameworks útils

També és convenient conéixer alguns frameworks populars i realment útils per al desenvolupament d’aplicacions web. Aquests frameworks es poden classificar depenent de si s’empren per a la part del client o la del servidor. En el primer cas, podem parlar d’Angular, React, Vue i alguns altres (encara que aquests són ara com ara els més populars), però per a l’apartat que ens interessa, que són els frameworks en el costat del servidor, ens centrarem en:

• Un framework per a desenvolupament d’aplicacions PHP. En aquest apartat, els més rellevants són Laravel i Symfony hui dia.
• Un framework per al desenvolupament d’aplicacions JavaScript. Actualment només existeix el framework Node.js que, al seu torn, permet instal·lar altres frameworks sobre ell per a facilitar el desenvolupament d’aplicacions. Per exemple, utilitzarem el framework Express.

6.3. Webs d’interés

A continuació s’enumeren algunes webs on consultar o descarregar els recursos indicats en aquest tema, per al desenvolupament d’aplicacions en entorn servidor.

• XAMPP - https://www.apachefriends.org/es/index.html
• Apache - https://www.apache.org
• Node.js - https://nodejs.org
• MongoDB - https://www.mongodb.com
• Express - https://expressjs.com
• Laravel - https://laravel.com
• Symfony - https://symfony.com

Exercici 3:

Utilitza l’eina Google Trends per a buscar els termes de Laravel, Symfony i Node.js. Dedueix a partir de les cerques quin d’ells creus que és més popular actualment. Després, acudeix a la web de InfoJobs i busca ofertes de treball amb aquests tres frameworks, per a determinar quin és el més demandat en l’actualitat.