Full stack developer

El stack, eina per eina.

Què hi ha a cada capa, per a què serveix cada peça i per què hi és aquesta i no una altra. Amb enllaç a la documentació oficial de cada una.

Backend NodeJS, TypeScript, Python, PHP, C#
Frontend React
Sistemes Linux, Apache, MySQL, PostgreSQL, MongoDB

Amb quin criteri es tria

L'eina es tria després del problema, mai abans. I gairebé sempre guanya la més avorrida de les que serveixen.

Un stack no és una llista de modes: és un conjunt de decisions que algú haurà de mantenir durant anys, de vegades sense que jo hi sigui. Per això pesa tant el que ja sap fer l'equip que es queda, i el que té documentació pública, versions amb suport i una comunitat a qui preguntar.

Manda el procés, no el llenguatge Primer què ha de passar i quines dades cal guardar. El llenguatge és l'última decisió, i de vegades la resposta és «el que ja feu servir».
El que és avorrit guanya Tecnologia amb anys, amb versions mantingudes i amb respostes a internet. El que és nou ha de justificar per què val el risc.
La dada sobreviu al codi L'aplicació es reescriu; les dades, no. El model relacional es dissenya per durar i les migracions es guarden com a part del projecte.
Una sola manera de fer cada cosa Dues maneres de llegir una configuració o tres de llançar una consulta és deute disfressat de llibertat.
Cada dependència es paga Cada biblioteca cal actualitzar-la, auditar-la i entendre-la el dia que falli. Si la seva feina són quaranta línies, s'escriuen.
La màquina també és el producte Sistema, servidor web, certificats i còpies formen part de l'entrega: una aplicació que no es pot desplegar dues vegades igual no està acabada.

Peça per peça.

Què és cada eina, per a què la faig servir i on és la seva documentació oficial.

NodeJS Entorn per executar JavaScript al servidor, amb un model d'entrada i sortida no blocant. Va bé quan la feina consisteix a esperar: moltes peticions simultànies que parlen amb bases de dades i amb APIs de tercers. Exemple: El backend d'una aplicació que consulta serveis externs mentre atén diversos usuaris a la vegada, sense obrir un procés per cada un. Font: Documentació de NodeJS
TypeScript JavaScript amb tipus comprovats abans d'executar. No canvia què fa el programa: canvia quan t'enteres que està malament, que passa a ser en escriure'l i no en producció. Exemple: Quan un camp del model passa d'obligatori a opcional, el compilador enumera els trenta llocs que cal revisar. Sense tipus, aquella llista l'escriu l'usuari que troba la fallada. Font: Documentació de TypeScript
Python Llenguatge de propòsit general, dels més llegibles que hi ha, amb biblioteca estàndard àmplia i un ecosistema fort en tractament de dades i automatització. Exemple: Els processos que no tenen pantalla: llegir un fitxer que envia un proveïdor, quadrar-lo amb el que hi ha a la base de dades i avisar de les diferències. Font: Documentació de Python 3
PHP Llenguatge pensat per al web, amb un model de petició simple —cada visita comença i acaba— i disponible a qualsevol allotjament. Des de la versió 8 té tipus, enumeracions i un compilador en temps d'execució. Exemple: Aquesta web, sense dependències i sense build. També els projectes que han de viure en un hosting compartit i sobreviure sense que ningú administri un servidor. Font: Manual de PHP
C# i .NET Llenguatge tipat i plataforma de Microsoft, amb eines molt sòlides i presència al programari de gestió d'empresa. És el terreny natural quan cal integrar-se amb sistemes del món Windows. Exemple: Integracions amb ERP i amb programari de gestió instal·lat a casa del client, on l'altra punta ja està escrita en aquell món. Font: Documentació de C#
APIs · HTTP i REST La manera com dos programes es parlen: adreces amb significat, mètodes amb semàntica i codis d'estat que volen dir alguna cosa. Està especificat als RFC de l'HTTP, no és qüestió de gust. Exemple: Que la botiga, la comptabilitat i el magatzem comparteixin el mateix client i el mateix estoc sense que ningú copiï dades a mà d'un programa a l'altre. Font: RFC 9110, HTTP Semantics (IETF)
React Biblioteca per construir interfícies per components, on la pantalla és el resultat d'un estat. Encaixa quan hi ha molta interacció i la mateixa dada es veu en diversos llocs a la vegada. Exemple: Un tauler on es filtra, s'ordena i s'edita sense recarregar, i on el comptador de dalt ha de quadrar sempre amb la taula de baix. Font: Documentació de React
Linux El sistema on acaba corrent gairebé tot. Saber administrar-lo és part de l'ofici: usuaris i permisos, serveis, certificats, tallafocs, còpies i registres. Exemple: Deixar una aplicació servida amb HTTPS, amb renovació automàtica del certificat, còpia diària comprovada i un lloc on mirar quan alguna cosa falla a les tres de la matinada. Font: The Twelve-Factor App
Apache HTTP Server Servidor web veterà i molt documentat, amb control fi de reescriptures, capçaleres i xifratge. És el que atén la petició abans que arribi a l'aplicació. Exemple: Les redireccions permanents de les adreces antigues d'un lloc, perquè un enllaç publicat fa deu anys continuï arribant on toca. Font: Documentació d'Apache 2.4
MySQL Base de dades relacional molt estesa i present a qualsevol allotjament. Compleix de sobres quan el model és clar i la càrrega, la normal d'una aplicació d'empresa. Exemple: La base d'una aplicació de gestió que viu en un hosting compartit i ha de poder moure's de proveïdor sense drama. Font: Manual de referència de MySQL
PostgreSQL Base de dades relacional amb regles estrictes, transaccions serioses i molta potència en consultes, JSON i tipus. És la que trio quan el model de dades és el centre del problema. Exemple: Un procés amb estats, dates i permisos on una consulta mal feta no pot retornar dades d'un altre client: millor que ho impedeixi la base de dades i no només el codi. Font: Documentació de PostgreSQL
MongoDB Base de dades de documents, sense esquema fix. Va bé quan el que es guarda són documents complets de forma variable; va mal quan en realitat hi havia relacions i es descobreix tard. Exemple: Guardar respostes d'un servei extern tal com arriben, amb els seus camps canviants, sense haver de refer l'esquema cada vegada que el proveïdor n'afegeix un. Font: Manual de MongoDB
Git El control de versions: la història de per què el codi està com està. Ben fet servir, l'historial contesta preguntes que cap comentari contesta. Exemple: Cada canvi amb el seu motiu escrit i el seu prefix, perquè les notes de versió surtin de l'historial i no de la memòria de ningú. Font: Documentació de Git

Preguntes.

Per què tants llenguatges i no un?

Perquè la feina no és sempre la mateixa i perquè molts encàrrecs consisteixen a integrar-se amb alguna cosa que ja existeix. Si l'ERP del client viu al món de Microsoft, la integració s'escriu allà; si el procés és un tractament de fitxers, Python ho resol en vint línies. Triar el llenguatge per gust propi ho paga després qui manté.

MySQL o PostgreSQL?

Si el model de dades és el cor del problema —estats, permisos, càlculs, informes—, PostgreSQL. Si cal que l'aplicació visqui a qualsevol allotjament i el model és senzill, MySQL compleix sense discussió. El que no faig és triar base de dades abans de tenir el model dibuixat.

I el mòbil?

Quan la feina de camp ha de dur alguna cosa a sobre, es fa aplicació mòbil connectada al mateix sistema, no una pantalla a part amb les seves pròpies dades. Kokai, per exemple, està publicada a l'App Store.

On s'allotja tot això?

On el projecte ho demani, amb una regla: si hi ha dades personals, l'allotjament es tria sabent què exigeix el Reglament General de Protecció de Dades, i això es decideix abans de desplegar, no després.

Documentació oficial i normes.

Cada eina enllaça a la seva documentació oficial, i el que és una norma, a la norma.

On continuar.

Parlem?

No saps què encaixa millor en el teu cas?

Explica'm el procés i et dic amb què ho faria i per què.

Escriu-me