Què és una aplicació full-stack? Explicació senzilla

Una aplicació full-stack és una aplicació que inclou totes les capes que necessita per funcionar: el frontend que la gent veu i clica, el backend que s'executa en un servidor i aplica les regles, i la base de dades que ho recorda tot. Una llista de tasques que desa les teves tasques, et deixa iniciar sessió des de qualsevol dispositiu i no mostra la teva llista a ningú més és full-stack. Una sola pàgina que només mostra l'horari d'obertura no ho és.

«Stack» (pila) vol dir simplement les capes de tecnologia apilades una sobre l'altra. «Full» vol dir que totes hi són.

Per què importa quan construeixes amb IA

Quan descrius una aplicació a un constructor amb IA, les paraules que facis servir decideixen quines capes construirà. «Fes una pàgina que mostri el nostre menú» produeix un frontend. «Deixa que els clients demanin del nostre menú i que la cuina vegi les comandes noves» necessita les tres capes, perquè les comandes s'han de desar, compartir entre dos tipus d'usuaris i mantenir privades.

Conèixer la diferència t'ajuda de tres maneres:

• Demanes la cosa adequada. Si vols que es desin les dades, digues-ho. Un constructor que només fa el frontend tindrà un aspecte acabat però ho oblidarà tot en actualitzar la pàgina.
• Detectes la falsa completesa. Una demo amb dades d'exemple pot semblar idèntica a una aplicació que funciona. Conèixer les capes et permet comprovar que les dades realment van a algun lloc.
• Entens els costos de funcionament. Un frontend sol es pot servir com a fitxers estàtics. Un backend i una base de dades són programes que s'executen en servidors, i d'aquí surt la major part del cost d'allotjament.

Una analogia: un restaurant

Pensa en un restaurant.

• La sala és el frontend. Els menús, les taules i la llibreta del cambrer. És el que veuen els clients, i ha de ser agradable i fàcil d'usar.
• La cuina és el backend. Els clients mai hi entren. Rep les comandes, comprova que el plat estigui disponible, el cuina i rebutja les peticions estranyes. Aquí és on viuen les regles.
• El rebost i el llibre de comandes són la base de dades. Guarden el que existeix i el que s'ha demanat, perquè no es perdi res quan canvia el torn.

Un restaurant amb només sala et pot ensenyar un menú bonic, però no et pot donar de menjar. Això és una aplicació només frontend fent-se passar per full-stack.

Les tres capes amb més detall

Les capes es comuniquen en un ordre fix. El frontend demana alguna cosa al backend mitjançant una API —un conjunt definit de peticions que accepta el backend. El backend comprova la petició, llegeix o escriu a la base de dades i envia una resposta. El frontend mai no parla directament amb la base de dades.

Aquest ordre és la idea de seguretat més important de tota la pila. Qualsevol cosa del frontend pot ser llegida i canviada pel visitant, perquè s'executa al seu dispositiu. Per tant, les regles —«només el propietari pot veure aquesta factura», «un cupó només es pot fer servir una vegada»— s'han d'aplicar al backend. Per saber més sobre la separació, consulta frontend contra backend.

Un exemple pràctic: una aplicació de reserves de classes

Digues que tens un estudi de ioga i vols que la gent reservi classes en línia.

Què fa el visitant: obre el lloc, veu les classes d'aquesta setmana, toca una, inicia sessió i reserva una plaça.

Què passa per sota:

1. El frontend mostra l'horari. Per omplir-lo, demana al backend: «Quines classes hi ha aquesta setmana i quantes places queden?»
2. El backend demana a la base de dades les classes i compta les reserves de cada una, i després respon.
3. El visitant toca Reservar. El frontend envia «reserva la classe 42 per a aquesta persona que ha iniciat sessió».
4. El backend comprova: aquesta persona realment ha iniciat sessió? La classe és plena? Ja l'ha reservada? Només si tot és correcte escriu una fila nova de reserva a la base de dades.
5. El backend respon «reservat», i el frontend mostra una confirmació.
6. Més tard, la propietària de l'estudi inicia sessió i veu la llista de classes. El backend comprova que és administradora abans de mostrar els noms de tothom.

Imagina ara que això s'hagués construït només amb frontend. L'horari es podria mostrar, i el botó Reservar podria mostrar un tic bonic, però la reserva desapareixeria en actualitzar la pàgina, el recompte de «places lliures» seria incorrecte per a tothom més, i la propietària mai no ho veuria. El pas 4 —les comprovacions— faltaria del tot. Aquesta és la diferència pràctica.

Termes clau

• Frontend (costat client): la part que s'executa al navegador.
• Backend (costat servidor): la part que s'executa en un servidor. També anomenat servidor d'API.
• Base de dades: on es guarden les dades de manera organitzada. Consulta què és una base de dades.
• API: la llista de peticions que accepta el backend des del frontend o d'altres programes.
• Autenticació: comprovar qui és algú (inici de sessió). Autorització: comprovar què pot fer.
• Desplegament: posar totes les capes en servidors perquè el públic les pugui fer servir.
• Monolit contra serveis: un sol programa que ho fa tot, contra diversos programes més petits (per exemple, un lloc web i una API separada). Totes dues són full-stack.

Errors i idees equivocades habituals

• «Sembla acabat, així que ho està.» Les dades d'exemple i un botó que sembla funcionar no són el mateix que dades desades. Actualitza la pàgina, obre-la en una finestra privada i comprova que les dades continuen allà.
• Posar les regles al frontend. Amagar un botó no és seguretat. Si el backend no ho comprova, qualsevol que conegui la petició la pot fer.
• Posar claus secretes al frontend. Una clau de pagament o d'IA al codi del navegador la pot llegir qualsevol visitant. Les claus pertanyen al backend, a les variables d'entorn; consulta variables d'entorn i secrets.
• Pensar que full-stack vol dir complicat. Una aplicació full-stack petita pot ser unes quantes pantalles, un grapat de rutes de backend i tres taules de base de dades. És una descripció de les capes, no de la mida.
• Pensar que has de triar tu mateix cada tecnologia. Qualsevol pila sensata i molt usada serveix per a una primera versió. El que importa més és una descripció clara de les dades i de les regles.

Què demanar al teu constructor amb IA

Descriu l'aplicació en termes de les tres capes, encara que no les anomenis:

• Les dades: «Desa les classes (nom, hora, capacitat) i les reserves (classe, persona, hora de reserva) en una base de dades.»
• Les regles: «No es pot reservar una classe si ja és plena. Una persona només pot reservar una classe una vegada. Només els administradors poden veure qui ha reservat.»
• Les pantalles: «Un horari setmanal, una confirmació de reserva, una pàgina d'administració que llisti les reserves per classe.»
• Les comprovacions: «Aplica aquestes regles al servidor, no només a la pàgina. Guarda qualsevol clau d'API al servidor.»

Despràs prova-ho amb escepticisme: actualitza, inicia sessió amb dues persones diferents, intenta veure dades que no hauries de veure. La guia per construir una aplicació amb IA recorre aquest cicle de principi a fi.

Aplicacions full-stack a Mythex

Mythex construeix aplicacions web full-stack a partir d'una descripció al xat. Per defecte, una aplicació nova obté un frontend amb React i TypeScript; quan l'aplicació necessita desar dades, Mythex afegeix al projecte una base de dades Postgres dedicada, i pots demanar un servidor d'API separat (per exemple, en Python, Node, C# o Java) al costat del lloc web. Tot s'executa junt en una previsualització en directe i es publica en un URL públic. La pàgina de la documentació sobre aplicacions multiservei mostra com un lloc web i una API es previsualitzen i es publiquen junts, i el constructor d'aplicacions full-stack ofereix punts de partida.

Preguntes