faketube.app
En los episodios anteriores construimos una base sólida del frontend para el proyecto, con shell de la aplicación, página de inicio responsiva e scroll infinito. Ahora avanzamos al backend, porque un clon de YouTube sin backend es como un coche sin motor: bonito pero inmóvil.
En este capítulo creamos los servicios backend esenciales siguiendo primero un enfoque tradicional con API REST y base de datos SQL y más adelante migraremos a una arquitectura moderna con GraphQL y NoSQL. Aprovechamos AWS y el enfoque Infrastructure as Code con AWS Cloud Development Kit CDK para definir y desplegar recursos de forma reproducible.
Resumen de la arquitectura: usaremos Amazon API Gateway, AWS Lambda y Amazon Aurora Serverless v2 PostgreSQL compatible. En el frontend consumiremos la API usando la librería AWS Amplify para Next.js que facilita las peticiones a API Gateway.
CDK es un framework open source que permite definir recursos en la nube con lenguajes familiares como TypeScript o Python en lugar de plantillas JSON o YAML. Para empezar instalar la CLI de CDK ejecutar sudo npm install -g aws-cdk y comprobar la versión con cdk --version.
Inicializar proyecto CDK: crear carpeta del proyecto, cdk init app --language typescript y organizar carpetas en web mobile cloud. Cambiar nombres y limpieza del stack por convención PascalCase.
Antes de desplegar realizar cdk bootstrap una sola vez por cuenta y región para crear el bucket S3 y roles IAM necesarios para despliegues. Usar cdk diff para previsualizar cambios antes de cdk deploy que sintetiza CloudFormation y crea los recursos.
Bases de datos: para este proyecto usamos Amazon Aurora Serverless v2 en edición compatible con PostgreSQL. Diseñamos el esquema con un ERD simple que incluye tablas channels y videos con una relación uno a muchos. Preferimos VARCHAR para campos como duration por compatibilidad con AWS CLI y Data API, evitando por ahora tipos INTERVAL que provocaron UnsupportedResultException.
DDL dividido en archivos por tabla porque aws rds-data execute-statement no soporta múltiples sentencias en una sola llamada. Ejemplos de sentencias: CREATE TABLE channels ( id VARCHAR(30) PRIMARY KEY, avatar VARCHAR(500) NOT NULL, name VARCHAR(255) NOT NULL ) y CREATE TABLE videos ( id VARCHAR(11) PRIMARY KEY, title VARCHAR(100) NOT NULL, thumbnail VARCHAR(500) NOT NULL, duration VARCHAR(20) NOT NULL, url VARCHAR(500) NOT NULL, published_at TIMESTAMP WITH TIME ZONE NOT NULL, channel_id VARCHAR(30) NOT NULL, CONSTRAINT fk_videos_channel_id FOREIGN KEY(channel_id) REFERENCES channels(id) ON DELETE CASCADE ).
Preparar datos semilla en archivos separados e insertarlos con aws rds-data execute-statement provisionando las variables de entorno con los outputs del stack. Ejemplo de export de variables tras deploy export FAKETUBE_AWS_AURORA_CLUSTER_ARN=arn:aws:rds:... export FAKETUBE_AWS_AURORA_CLUSTER_SECRET_ARN=arn:aws:secretsmanager:... export FAKETUBE_AWS_AURORA_DATABASE_NAME=faketube.
Crear la VPC y lanzar Aurora dentro de subnets PRIVATE_ISOLATED. En CDK definir una construct VPC que crea subredes aisladas y no expone Internet Gateway. Al desplegar Aurora configurar engine auroraPostgres con version adecuada, enableDataApi true para usar Data API y políticas de removalPolicy DESTROY en pruebas; en producción usar SNAPSHOT o RETAIN. Ajustar serverlessV2MinCapacity y MaxCapacity y auto pause duration según necesidades.
Tras desplegar via cdk deploy aplicar las sentencias SQL con aws rds-data execute-statement y comprobar resultados con una consulta de verificación que haga JOIN entre videos y channels y devuelva paginación con LIMIT y OFFSET. Si la base se ha pausado por auto pause esperar a que reanude antes de ejecutar comandos.
API: definimos contrato OpenAPI para la funcionalidad Home con endpoint GET videos que acepta parámetros page y pageSize y devuelve un esquema Page que contiene items currentPage y hasNextPage. Aunque API Gateway permite importar OpenAPI, en este caso creamos la API con constructs de CDK para tener control y añadimos tanto REST como HTTP API para comparar ventajas.
Configurar CORS vía defaultCorsPreflightOptions para REST y corsPreflight para HTTP leyendo orígenes permitidos desde el contexto del CDK, por ejemplo localhost y el dominio de producción. Añadir outputs del stack con las URL de API Gateway para usarlas en pruebas y en la configuración del frontend.
Lambda: usamos una construct personalizada Lambda que simplifica la creación de funciones Node.js con NodejsFunction, runtime NodeJS latest, arquitectura ARM 64 y permite añadir variables de entorno comunes como CORS_ORIGINS. El handler utiliza Middy para middlewares y AWS Powertools para logging tracing y métricas. Middy valida inputs, maneja CORS y errores y permite inyectar variables de entorno obligatorias en tiempo de arranque.
Dependencias clave para el handler instalar esbuild y tipos de aws lambda, Middy con @middy/core @middy/http-cors @middy/http-error-handler @middy/validator middy-env y Powertools con @aws-lambda-powertools/logger @aws-lambda-powertools/metrics @aws-lambda-powertools/tracer.
Modelos TypeScript para Channel Video y Page definen la forma de los datos que la API devuelve. El handler inicial devuelve una page vacía para validar despliegue y endpoints. Posteriormente integramos la base de datos usando data-api-client que permite ejecutar consultas parametrizadas contra Aurora Data API sin gestionar conexiones persistentes.
Ejecutar consulta SELECT con window function count over para obtener total y construir items transformando registros a objetos Video con channel embebido. Calcular hasNextPage comparando page actual con total pages.
Probar endpoints con curl apuntando a REST o HTTP según las variables exportadas. Ejemplos de uso comprobar JSON de respuesta y validar que paginación y datos coinciden con los seeds insertados.
Para facilitar la documentación y pruebas interactivas usar Swagger Editor con el archivo OpenAPI y añadir servers que apunten a las URL de API Gateway y permitir editor.swagger.io como origen CORS temporal para poder ejecutar peticiones desde el editor.
Frontend: integrar AWS Amplify en la app Next.js instalando aws-amplify y creando un archivo de configuración amplify-configuration que registra endpoints REST y HTTP y la región leída desde variables de entorno NEXT_PUBLIC. Crear componente ConfigureAmplifyClientSide que configura Amplify en el cliente con SSR true y envolver providers con ese componente para inicializar Amplify antes de renderizar.
Hook useListVideos: permitir alternar entre modo mock rest y http mediante la variable NEXT_PUBLIC_FAKETUBE_API_TYPE_SWITCH. Implementar fetchMock que consume datos locales y fetchApi que usa get de aws-amplify api para invocar el API Gateway pasando queryParams page y pageSize. Usar react query useInfiniteQuery para manejar paginación e infinite scroll.
Configurar web .env con NEXT_PUBLIC_FAKETUBE_AWS_REGION NEXT_PUBLIC_FAKETUBE_AWS_API_GATEWAY_REST_ENDPOINT NEXT_PUBLIC_FAKETUBE_AWS_API_GATEWAY_REST_NAME NEXT_PUBLIC_FAKETUBE_AWS_API_GATEWAY_HTTP_ENDPOINT NEXT_PUBLIC_FAKETUBE_AWS_API_GATEWAY_HTTP_NAME y NEXT_PUBLIC_FAKETUBE_API_TYPE_SWITCH para cambiar entre mock rest y http. Actualizar variables de entorno en Amplify Hosting para builds de producción.
Pruebas: cambiar NEXT_PUBLIC_FAKETUBE_API_TYPE_SWITCH a rest o http y comprobar que la grid de la home se llena con datos reales. Usar Chrome DevTools para inspeccionar peticiones network y validar headers CORS y respuestas JSON.
Consideraciones operativas: revisar warnings de Aurora sobre readers serverless y promotion tiers porque en producción conviene tener lectores que escalen con el writer para evitar lag en replicación. Ajustar removalPolicy en entornos productivos para no perder datos.
Resumen y siguiente pasos: con esta entrega tenemos infraestructura definida como código, base de datos Aurora Serverless poblada, API REST y HTTP expuestos a través de API Gateway y un Lambda robusto con observabilidad listo para producir datos a la UI. En futuras iteraciones añadiremos autenticación, endpoints adicionales, tests automatizados y exploraremos una alternativa con DynamoDB y GraphQL para comparar modelos y costes.
Sobre Q2BSTUDIO: Q2BSTUDIO es una empresa de desarrollo de software especializada en aplicaciones a medida software a medida inteligencia artificial ciberseguridad y servicios cloud aws y azure. Ofrecemos servicios de inteligencia de negocio ia para empresas agentes IA power bi y soluciones completas que incluyen diseño desarrollo despliegue y soporte. Si necesita una solución personalizada para su negocio podemos ayudarle a definir arquitectura segura escalable y optimizada para sus requisitos.
Palabras clave y posicionamiento: aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws servicios cloud azure servicios inteligencia de negocio ia para empresas agentes IA power bi. Incorporar estas capacidades en su proyecto mejora la competitividad la eficiencia y la seguridad.
Contacto: si desea que Q2BSTUDIO colabore en su proyecto de backend cloud o en soluciones de inteligencia artificial y business intelligence póngase en contacto para una consultoría inicial y propuesta técnica a medida.
Fin del resumen tecnico y guía practica para implementar Videos REST API with API Gateway Lambda Aurora Serverless FakeTube episodio 5 y para integrar el backend con el frontend usando AWS Amplify y Next.js