Full stack developer

El stack, herramienta por herramienta.

Qué hay en cada capa, para qué sirve cada pieza y por qué está ahí y no otra. Con enlace a la documentación oficial de cada una.

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

Con qué criterio se elige

La herramienta se elige después del problema, nunca antes. Y casi siempre gana la más aburrida de las que sirven.

Un stack no es una lista de modas: es un conjunto de decisiones que alguien va a tener que mantener durante años, a veces sin que yo esté. Por eso pesa tanto lo que ya sabe hacer el equipo que se queda, y lo que tiene documentación pública, versiones con soporte y una comunidad a la que preguntar.

Manda el proceso, no el lenguaje Primero qué tiene que pasar y qué datos hay que guardar. El lenguaje es la última decisión, y a veces la respuesta es «lo que ya usáis».
Lo aburrido gana Tecnología con años, con versiones mantenidas y con respuestas en internet. Lo nuevo tiene que justificar por qué merece el riesgo.
El dato sobrevive al código La aplicación se reescribe; los datos, no. El modelo relacional se diseña para durar y las migraciones se guardan como parte del proyecto.
Una sola forma de hacer cada cosa Dos maneras de leer una configuración o tres de lanzar una consulta es deuda disfrazada de libertad.
Cada dependencia se paga Cada biblioteca hay que actualizarla, auditarla y entenderla el día que falle. Si su trabajo son cuarenta líneas, se escriben.
La máquina también es el producto Sistema, servidor web, certificados y copias forman parte de la entrega: una aplicación que no se puede desplegar dos veces igual no está terminada.

Pieza por pieza.

Qué es cada herramienta, para qué la uso y dónde está su documentación oficial.

NodeJS Entorno para ejecutar JavaScript en el servidor, con un modelo de entrada y salida no bloqueante. Va bien cuando el trabajo consiste en esperar: muchas peticiones simultáneas que hablan con bases de datos y con APIs de terceros. Ejemplo: El backend de una aplicación que consulta servicios externos mientras atiende a varios usuarios a la vez, sin abrir un proceso por cada uno. Fuente: Documentación de NodeJS
TypeScript JavaScript con tipos comprobados antes de ejecutar. No cambia lo que el programa hace: cambia cuándo te enteras de que está mal, que pasa a ser al escribirlo y no en producción. Ejemplo: Cuando un campo del modelo pasa de obligatorio a opcional, el compilador enumera los treinta sitios que hay que revisar. Sin tipos, esa lista la escribe el usuario que encuentra el fallo. Fuente: Documentación de TypeScript
Python Lenguaje de propósito general, de los más legibles que hay, con biblioteca estándar amplia y un ecosistema fuerte en tratamiento de datos y automatización. Ejemplo: Los procesos que no tienen pantalla: leer un fichero que manda un proveedor, cuadrarlo con lo que hay en la base de datos y avisar de las diferencias. Fuente: Documentación de Python 3
PHP Lenguaje pensado para la web, con un modelo de petición simple —cada visita empieza y acaba— y disponible en cualquier alojamiento. Desde la versión 8 tiene tipos, enumeraciones y un compilador en tiempo de ejecución. Ejemplo: Esta web, sin dependencias y sin build. También los proyectos que tienen que vivir en un hosting compartido y sobrevivir sin que nadie administre un servidor. Fuente: Manual de PHP
C# y .NET Lenguaje tipado y plataforma de Microsoft, con herramientas muy sólidas y presencia en el software de gestión de empresa. Es el terreno natural cuando hay que integrarse con sistemas del mundo Windows. Ejemplo: Integraciones con ERP y con software de gestión instalado en casa del cliente, donde la otra punta ya está escrita en este mundo. Fuente: Documentación de C#
APIs · HTTP y REST La forma en que dos programas se hablan: direcciones con significado, métodos con semántica y códigos de estado que quieren decir algo. Está especificado en los RFC del HTTP, no es cuestión de gusto. Ejemplo: Que la tienda, la contabilidad y el almacén compartan el mismo cliente y el mismo stock sin que nadie copie datos a mano de un programa a otro. Fuente: RFC 9110, HTTP Semantics (IETF)
React Biblioteca para construir interfaces por componentes, donde la pantalla es el resultado de un estado. Encaja cuando hay mucha interacción y el mismo dato se ve en varios sitios a la vez. Ejemplo: Un panel donde se filtra, se ordena y se edita sin recargar, y donde el contador de arriba tiene que cuadrar siempre con la tabla de abajo. Fuente: Documentación de React
AngularJS El primer Angular, de 2010. Su soporte terminó oficialmente y no es una opción para empezar nada: aparece aquí porque hay aplicaciones en producción escritas con él que siguen dando servicio y hay que mantenerlas con criterio. Ejemplo: Sostener una aplicación heredada mientras se decide qué pantallas merecen rehacerse y cuáles se quedan como están hasta que se jubilen. Fuente: Estado del soporte de AngularJS
Linux El sistema donde acaba corriendo casi todo. Saber administrarlo es parte del oficio: usuarios y permisos, servicios, certificados, cortafuegos, copias y registros. Ejemplo: Dejar una aplicación servida con HTTPS, con renovación automática del certificado, copia diaria comprobada y un sitio donde mirar cuando algo falla a las tres de la mañana. Fuente: The Twelve-Factor App
Apache HTTP Server Servidor web veterano y muy documentado, con control fino de reescrituras, cabeceras y cifrado. Es lo que atiende la petición antes de que llegue a la aplicación. Ejemplo: Las redirecciones permanentes de las direcciones antiguas de un sitio, para que un enlace publicado hace diez años siga llegando a su sitio. Fuente: Documentación de Apache 2.4
MySQL Base de datos relacional muy extendida y presente en cualquier alojamiento. Cumple sobradamente cuando el modelo es claro y la carga, la normal de una aplicación de empresa. Ejemplo: La base de una aplicación de gestión que vive en un hosting compartido y tiene que poder moverse de proveedor sin drama. Fuente: Manual de referencia de MySQL
PostgreSQL Base de datos relacional con reglas estrictas, transacciones serias y mucha potencia en consultas, JSON y tipos. Es la que elijo cuando el modelo de datos es el centro del problema. Ejemplo: Un proceso con estados, fechas y permisos donde una consulta mal hecha no puede devolver datos de otro cliente: mejor que lo impida la base de datos y no solo el código. Fuente: Documentación de PostgreSQL
MongoDB Base de datos de documentos, sin esquema fijo. Va bien cuando lo que se guarda son documentos completos de forma variable; va mal cuando en realidad había relaciones y se descubre tarde. Ejemplo: Guardar respuestas de un servicio externo tal como llegan, con sus campos cambiantes, sin tener que rehacer el esquema cada vez que el proveedor añade uno. Fuente: Manual de MongoDB
Git El control de versiones: la historia de por qué el código está como está. Bien usado, el historial contesta preguntas que ningún comentario contesta. Ejemplo: Cada cambio con su motivo escrito y su prefijo, para que las notas de versión salgan del historial y no de la memoria de nadie. Fuente: Documentación de Git

Preguntas.

¿Por qué tantos lenguajes y no uno?

Porque el trabajo no es siempre el mismo y porque muchos encargos consisten en integrarse con algo que ya existe. Si el ERP del cliente vive en el mundo de Microsoft, la integración se escribe ahí; si el proceso es un tratamiento de ficheros, Python lo resuelve en veinte líneas. Elegir el lenguaje por gusto propio lo paga después quien mantiene.

¿AngularJS no está descatalogado?

Sí, y no se empieza nada nuevo con él. Está en la lista porque hay aplicaciones en producción escritas con AngularJS que siguen funcionando y necesitan mantenimiento: fingir que no existen no las arregla. Lo honesto es sostenerlas y planificar qué se rehace y cuándo.

¿MySQL o PostgreSQL?

Si el modelo de datos es el corazón del problema —estados, permisos, cálculos, informes—, PostgreSQL. Si hace falta que la aplicación viva en cualquier alojamiento y el modelo es sencillo, MySQL cumple sin discusión. Lo que no hago es elegir base de datos antes de tener el modelo dibujado.

¿Y el móvil?

Cuando el trabajo de campo tiene que llevar algo encima, se hace aplicación móvil conectada al mismo sistema, no una pantalla aparte con sus propios datos. Kokai, por ejemplo, está publicada en el App Store.

¿Dónde se aloja todo esto?

Donde el proyecto lo pida, con una regla: si hay datos personales, el alojamiento se elige sabiendo qué exige el Reglamento General de Protección de Datos, y eso se decide antes de desplegar, no después.

Documentación oficial y normas.

Cada herramienta enlaza a su documentación oficial, y lo que es una norma, a la norma.