Serverless en JavaScript: Cómo dejar de pensar en servidores y empezar a escribir código
\n\nImagina: escribiste un servicio genial, lo lanzaste, y al mes nadie lo necesita. Pagas por un servidor que está inactivo. O al revés — te llega un pico de tráfico inesperado, el servidor se cae, y a las 3 de la mañana estás arreglando nginx. ¿Te suena? Hay una forma de librarse de ese dolor de cabeza: las funciones serverless en JavaScript.
\n\nServerless (o computación sin servidor) no es magia, es un modelo donde solo escribes código, y el proveedor (AWS, Google, Yandex) decide cuándo, dónde y cuántos recursos asignar. Pagas solo por el tiempo de ejecución y la cantidad de solicitudes. Nada de máquinas virtuales "siempre encendidas". Para un desarrollador de JavaScript es especialmente cómodo: Node.js es el entorno nativo para AWS Lambda, Google Cloud Functions y Yandex Cloud Functions.
\n\nEn este artículo no solo hablaremos de teoría. Escribiremos funciones reales, compararemos proveedores y te daremos una lista de verificación para que no cometas errores. ¡Allá vamos!
\n\n¿Qué es una función serverless y para qué sirve a un desarrollador JS?
\n\nUna función serverless es un fragmento de código (normalmente una función) que se ejecuta en respuesta a un evento. El evento puede ser una solicitud HTTP, la subida de un archivo a S3, una escritura en la base de datos o incluso una señal de un temporizador (cron).
\n\nPor qué es cómodo para JavaScript:
\n- \n
- Inicio rápido — no necesitas configurar un servidor, solo subir el código. \n
- Autoescalado — la función se replica sola bajo demanda. \n
- Ahorro — mientras nadie llame a la función, no pagas ni un céntimo. \n
- Ecosistema — Node.js es compatible con todos los grandes proveedores. \n
Casos de uso típicos: procesamiento de webhooks, generación de vistas previas de imágenes, envío de correos, validación de formularios, análisis de datos, creación de microservicios. Todo lo que se pueda ejecutar bajo demanda.
\n\nAWS Lambda — el rey del serverless JavaScript
\n\nAmazon Web Services Lambda es el servicio más popular. Fue el primero y sigue marcando los estándares. Escribamos una función simple que recibe un JSON y devuelve una respuesta.
\n\nCódigo para AWS Lambda en Node.js 20:
\n\nexport const handler = async (event) => {\n try {\n const { name } = JSON.parse(event.body || '{}');\n const message = `¡Hola, ${name || 'invitado'}! Has llamado exitosamente a una función serverless.`;\n \n return {\n statusCode: 200,\n headers: {\n 'Content-Type': 'application/json',\n 'Access-Control-Allow-Origin': '*',\n },\n body: JSON.stringify({ message, timestamp: Date.now() }),\n };\n } catch (error) {\n return {\n statusCode: 400,\n body: JSON.stringify({ error: 'JSON no válido' }),\n };\n }\n};\n\nObserva: la función se llama handler. Es el nombre estándar para el punto de entrada. El parámetro event contiene todo lo que llega desde API Gateway: cabeceras, cuerpo, parámetros de la solicitud. Devuelves un objeto con statusCode y body.
Cómo funciona: creas una función en la consola de AWS, subes el código (o usas SAM/Serverless Framework), configuras un disparador — por ejemplo, un endpoint HTTP a través de API Gateway. Y listo. El mundo se ha vuelto más simple.
\n\nArranque en frío y cómo lidiar con él
\n\nEl principal inconveniente de Lambda es el arranque en frío. Si la función no se ha llamado durante mucho tiempo, en la primera solicitud el entorno se carga de nuevo. Esto puede llevar de 200 a 500 ms. Para APIs de alta carga, esto es crítico. Soluciones:
\n- \n
- Mantén la función "caliente" con CloudWatch Events (haz un ping cada 5 minutos). \n
- Reduce el tamaño del paquete — no incluyas paquetes npm innecesarios. \n
- Usa Provisioned Concurrency (pero es más caro). \n
Para la mayoría de los microservicios, el arranque en frío no es un problema. Pero si estás escribiendo un chatbot donde la velocidad es importante, tenlo en cuenta.
\n\nGoogle Cloud Functions — simplicidad e integración con Firebase
\n\nGo