Què és un servidor? Guia en llenguatge senzill per a constructors d'aplicacions

Un servidor és un ordinador —o un programa que s'executa en un— que espera peticions i les respon. Quan obres un lloc web, el teu navegador (el client) envia una petició per internet, i algun servidor en algun lloc retorna la pàgina, les imatges o les dades. Totes les aplicacions que uses, des del correu fins a la banca en línia, depenen de servidors que fan això milions de cops al dia.

Per què els servidors importen quan construeixes amb IA

Quan un constructor amb IA et fa una aplicació, part del codi s'executa al navegador del visitant i part normalment s'executa en un servidor. La part del servidor fa les coses que el navegador no es pot confiar que faci o no pot fer per si sol:

• Desar i carregar dades d'una base de dades.
• Guardar secrets, com les claus d'API de pagaments o de proveïdors d'IA, que mai no han d'arribar al navegador.
• Comprovar permisos —assegurant que un usuari només pot veure i canviar els seus propis registres.
• Parlar amb altres serveis: cobrar una targeta, enviar un correu, cridar un model d'IA.

Saber què fa el servidor t'ajuda a entendre on viuen de debò les regles de la teva aplicació, per què alguns canvis necessiten tornar a publicar, i què estàs pagant quan allotges una aplicació. Per a la divisió entre les dues parts, consulta frontend contra backend.

Una analogia del dia a dia

Un servidor és com el personal del taulell d'una oficina de correus. No surt a buscar clients; espera. Un client s'apropa amb una petició —«envia aquest paquet», «tinc correu?»— i el funcionari la gestiona i retorna un resultat. Un sol funcionari pot atendre molts clients un darrere l'altre, i una oficina ocupada obre més taulells.

L'oficina de correus també té regles que el client no pot saltar-se: has de mostrar el DNI per recollir un paquet. Això és la feina del servidor en una aplicació també: el navegador pot demanar qualsevol cosa, però el servidor decideix què obté.

Com arriba una petició a un servidor

Quan algú visita https://bookings.example.com/schedule:

1. Consulta DNS. El navegador demana al sistema de noms de domini a quina adreça IP apunta bookings.example.com. Consulta com funcionen els dominis i el DNS.
2. Connexió. El navegador es connecta a aquesta adreça, pel port 443 per a HTTPS, i estableix una connexió xifrada. Consulta què és HTTPS.
3. Petició. Envia una petició HTTP: GET /schedule.
4. Feina. El servidor executa el codi que gestiona /schedule —potser cerca les reserves d'avui a la base de dades.
5. Resposta. Retorna un codi d'estat (200 OK) i el contingut: una pàgina HTML o dades JSON perquè la pàgina les mostri.

Tot això normalment triga una fracció de segon.

Tipus de servidors que sentiràs

Ten en compte que «servidor» vol dir tant la màquina com el programa. «El servidor s'ha caigut» pot voler dir qualsevol dels dos.

Un exemple pràctic: una aplicació de reserves per a una perruqueria

Així és el que fa el servidor en una petita aplicació de reserves per a una perruqueria:

• Un visitant obre el lloc. El servidor (o una CDN davant seu) envia els fitxers de la pàgina.
• La pàgina demana al servidor GET /api/slots?date=2026-10-03. El servidor consulta la base de dades per trobar les franges lliures i les retorna en JSON.
• El visitant reserva les 14:00. La pàgina envia POST /api/bookings. El servidor comprova que la franja encara és lliure —no es fia de la paraula del navegador—, desa la reserva i retorna 201 Created.
• El servidor crida un servei de correu amb una clau secreta, guardada al servidor, per enviar la confirmació.

Si apagues el servidor, la pàgina potser encara es carregaria des d'una CDN, però no podria mostrar franges ni desar reserves.

Què necessita un servidor per funcionar bé

• Memòria (RAM) i CPU. Amb poca memòria l'aplicació es cau sota càrrega; amb poca CPU, va lenta.
• Estar en marxa. Un servidor apagat no pot respondre. Alguns proveïdors adormen les aplicacions inactives i les desperten amb la següent visita, cosa que estalvia diners però pot fer la primera petició més lenta.
• Configuració i secrets, proporcionats com a variables d'entorn.
• Registres (logs): el registre del servidor del que ha passat, que és el primer lloc on mirar quan alguna cosa falla.
• Actualitzacions i parxes de seguretat, que l'allotjament gestionat fa per tu.

Idees equivocades habituals

• «El núvol vol dir que no hi ha servidors». El núvol són servidors d'altres empreses, llogats per hora o per ús.
• «Un servidor és un ordinador especial i gran». Qualsevol ordinador pot fer de servidor. El teu portàtil n'executa un quan obres localhost durant el desenvolupament.
• «Si el botó està amagat, els usuaris no ho poden fer». Qualsevol pot enviar peticions directament al teu servidor. Les comprovacions de permisos s'han de fer al servidor, no només a la pàgina.
• «Més servidors arreglen la lentitud». Sovint la causa real és una consulta lenta a la base de dades o una API externa. Troba primer el coll d'ampolla.
• «Necessito gestionar un servidor per tenir una aplicació». Les plataformes gestionades executen els servidors per tu; tu despleguis el codi i elles s'encarreguen de les màquines.

Què demanar al teu constructor amb IA

• «Quines parts d'aquesta aplicació s'executen al servidor i quines s'executen al navegador?»
• «Guarda totes les claus d'API al servidor i llegeix-les de variables d'entorn.»
• «Comprova els permisos al servidor per a cada petició que llegeix o canvia dades.»
• «On trobo els registres del servidor, i què diuen sobre aquest error?»
• «Aquesta aplicació necessita un servidor, o pot ser un lloc estàtic?»
• «Què passa amb la primera petició després que l'aplicació hagi estat inactiva?»

Servidors a Mythex

A Mythex no has de configurar ni gestionar servidors. Mentre construeixes, la teva aplicació s'executa en un entorn de núvol privat per a la previsualització en directe. Quan publiques, Mythex la desplega: els frontends estàtics com a llocs estàtics, i els backends (Node, Python, C#, Java i altres) com a contenidors construïts a partir d'un Dockerfile —sense cap allotjament que hagis de configurar tu. Mythex tria la mida de la màquina quan desplega: per defecte 1 CPU i 512 MB de memòria, amb més disponible a petició (fins a 1 GB al Free, i fins a 2 CPU, 4 GB i 3 màquines al Pro). Les aplicacions publicades s'adormen quan estan inactives i es desperten a la següent visita, i una aplicació adormida no gasta res en còmput. Els detalls són a la documentació sobre backends d'API i límits d'allotjament, i la nostra guia sobre allotjament web cobreix el panorama més ampli.

Preguntes