ArvinAbrahamian1/production-app

Aplicación de Producción

La idea

Cada gran empresa converge en la misma forma: un edge al frente, un frontend desplegable, un backend separado detrás de una puerta de enlace, workers que consumen de una cola, un sistema relacional de registro, una caché, una columna vertebral de eventos o trabajos, almacenamiento de objetos y observabilidad alrededor de todo. Shopify, Notion, Figma, Instacart y Airbnb difieren en lenguajes y proveedores, no en la forma.

La forma no cambia entre un MVP de fin de semana y una empresa con un equipo de plataforma. Solo cambia el proveedor detrás de cada caja. Por lo tanto, este skill construye la forma completa desde el día uno con proveedores administrados económicos, impone una lista corta de reglas de portabilidad y mantiene un manual por capa para intercambiar el proveedor cuando se activa un desencadenante medible. Hecho de esta manera, pasar de Vercel y Supabase a Kubernetes y RDS es una serie de cambios de configuración y copias de datos, nunca una reescritura.

Cómo usar este skill

1. Lee la descripción del proyecto. Haz las preguntas de ingesta a continuación solo sobre lo que la descripción omita.
2. Elige un proveedor por capa con references/providers-and-tiers.md. Comienza en el nivel 1 a menos que una regla de selección indique lo contrario.
3. Escribe docs/PLAN.md a partir de la plantilla a continuación, incluyendo el diagrama adaptado de references/architecture.md, y muéstralo antes de comenzar el andamiaje.
4. Andamia y construye en el orden que sigue.
5. Antes del lanzamiento, ejecuta references/launch-checklist.md e informa solo las fallas con sus correcciones.
6. Cuando se active un desencadenante más tarde, abre references/migrations.md y mueve esa capa. Nunca muevas dos capas en la misma semana.

Para una aplicación existente: audita primero. Mapea el repositorio en la forma, enumera las brechas ordenadas por riesgo (fuga de datos, caída, abuso, bloqueo, costo) y detente. Los cambios vienen después de que el propietario elija de la lista.

Ingesta

Pregunta solo lo que la descripción deje sin respuesta, en un solo mensaje.

1. ¿Quiénes son los usuarios y cuál es el inquilino: la unidad que posee los datos (una empresa, un edificio, un concesionario, una sola persona)?
2. ¿Qué es pesado: feeds, mensajes, cargas, video, eventos, búsqueda? ¿Filas o archivos aproximados por día y crecimiento?
3. ¿Web, iOS, Android o una combinación? ¿Cuál se lanza primero?
4. Necesidades en tiempo real: chat, presencia en vivo, edición colaborativa, o ¿es suficiente el polling?
5. Dinero: suscripciones, pagos únicos, pagos de mercado, ¿ninguno?
6. ¿Algo regulado o sensible: pagos almacenados, salud, menores, ubicación, compradores gubernamentales o empresariales que solicitarán SOC 2?
7. Geografía de la audiencia: ¿un país o global?
8. Restricciones: créditos existentes en la nube, un proveedor existente, un lenguaje requerido.

Las respuestas impulsan las reglas de selección en references/providers-and-tiers.md.

La forma

Cada capa tiene un rol, una referencia de una gran empresa y la única regla que la mantiene portátil. Los proveedores por nivel se encuentran en references/providers-and-tiers.md.

1. Edge: DNS, TLS, CDN, DDoS, WAF, limitación de velocidad, filtrado de bots, frente a cada host. Grandes empresas: Cloudflare, Akamai, Fastly, CloudFront con AWS WAF. Regla: tú eres dueño de la zona DNS; cada proveedor se coloca detrás de un CNAME, por lo que cambiar de proveedor es un cambio de DNS.
2. Frontend: un desplegable separado, estático o renderizado en servidor, que no contiene lógica de negocio ni acceso a la base de datos. Grandes empresas: una aplicación React o Next.js compilada en un contenedor y servida a través de la CDN. Regla: el frontend se compila como un contenedor Node estándar o un paquete estático y se comunica solo con la API pública.
3. Puerta de enlace (Gateway): un balanceador de carga o puerta de enlace API que termina TLS desde el edge, enruta por ruta y aplica límites generales. Grandes empresas: ALB, Envoy, NGINX ingress, Kong. Regla: la API nunca depende de funciones de la puerta de enlace que no pueda reproducir en su propio middleware.
4. Backend: un servicio monolito detrás de la puerta de enlace, dividido en servicios solo cuando los equipos chocan. Grandes empresas: Rails en Shopify y GitHub, Django en Instagram, Node en Notion, gRPC por dentro, GraphQL o REST por fuera. Regla: un contenedor Docker con un endpoint de salud, configuración desde env, sin SDK de proveedor en la lógica de negocio.
5. Workers y cola: procesos separados de larga duración que consumen trabajos; un motor de flujo de trabajo cuando los trabajos tienen múltiples pasos o esperas humanas. Grandes empresas: Sidekiq y consumidores de Kafka en Shopify, Temporal en Netflix y Duolingo, Kafka en Notion. Regla: los trabajos son idempotentes, llevan IDs no blobs, y la cola es protocolo Redis o Kafka estándar.
6. Base de datos relacional: un primario de Postgres (o MySQL) como sistema de registro, réplicas para lecturas, fragmentación solo más allá de los límites de una sola máquina. Grandes empresas: RDS Postgres con PgBouncer en Notion y Figma, más de 100 fragmentos MySQL en Shopify. Regla: solo protocolo Postgres, migraciones SQL en el repositorio, roles y RLS en SQL, nada que solo funcione en la API de un proveedor.
7. Caché: Redis o Memcached para lecturas activas, contadores de límite de velocidad, bloqueos, sesiones. Regla: protocolo Redis estándar, claves con ámbito de inquilino y versionadas, la aplicación debe poder ejecutarse con la caché vacía.
8. Almacenamiento de objetos: S3 o un bucket compatible con S3 para cada archivo; nunca la base de datos. Regla: solo API S3, claves con prefijo de inquilino, servido a través de URL firmadas o la CDN.
9. Identidad: un proveedor de identidad que emite JWTs, una tabla users propiedad de la aplicación. Grandes empresas: interno más Okta o Auth0 para SSO empresarial. Regla: la API verifica los tokens por sí misma mediante JWKS y es dueña de la tabla de usuarios, por lo que el emisor puede cambiar.
10. Eventos y analítica: analítica de productos y, más tarde, un almacén de datos alimentado por captura de cambios de datos. Grandes empresas: Kafka en Snowflake o BigQuery. Regla: el almacén de datos lee de la base de datos, nunca escrituras duales desde la aplicación.
11. Observabilidad: registros estructurados, errores, métricas, trazas, tiempo de actividad, alertas vinculadas a un runbook. Grandes empresas: Datadog, Grafana, Honeycomb, Sentry, OpenTelemetry. Regla: la aplicación emite OpenTelemetry y registros JSON, por lo que el backend es una configuración de exportador.
12. Entrega: CI en cada push, infraestructura como código, despliegues canary o blue-green, feature flags, reversión rápida. Grandes empresas: Terraform, Buildkite o GitHub Actions, ArgoCD o Spinnaker, LaunchDarkly. Regla: cualquier cosa clickeada en un panel de control se escribe en infra/ el mismo día, y Terraform desde el nivel 2.

Reglas de portabilidad

Estas son las que hacen que la migración posterior sea económica. Cuestan casi nada en el tamaño MVP y son la diferencia entre una migración de fin de semana y una reescritura de un trimestre.

1. Frontend y backend son repositorios separados y desplegables separados desde el primer commit. Se comunican a través de una API HTTP versionada con esquemas compartidos.
2. El backend y el worker son imágenes Docker que se ejecutan en cualquier lugar donde se ejecute un contenedor. Sin funciones serverless para la API: las funciones de Vercel, los controladores Lambda y las funciones edge son lo único que no se puede migrar a un contenedor más tarde sin reescribir.
3. Comunícate con la infraestructura solo a través de estándares: protocolo Postgres wire, protocolo Redis, API S3, SMTP o una API HTTP de correo electrónico detrás de una interfaz, JWKS para tokens, OpenTelemetry para telemetría. La biblioteca cliente propia de un proveedor solo se permite en un módulo adaptador delgado que se pueda intercambiar.
4. Sin funciones de proveedor en la lógica de negocio: sin llamadas a PostgREST, sin cliente Supabase o Firebase en el backend, sin APIs de caché específicas de Vercel, sin Workers KV. El frontend puede usar el SDK de autenticación de un proveedor solo para iniciar sesión.
5. La aplicación es dueña de su esquema: migraciones SQL en el repositorio, aplicadas por una herramienta de migración, nunca desde un panel de control. Roles, RLS y funciones son archivos SQL que el repositorio puede reproducir en cualquier Postgres.
6. La aplicación es dueña de sus usuarios: una tabla users reflejada desde el proveedor de identidad en el primer inicio de sesión, con los IDs de proveedor almacenados como una columna. Los datos de permisos residen en las tablas de la aplicación.
7. La configuración son variables de entorno validadas al arrancar. Los secretos residen en el almacén de secretos de la plataforma, pero llegan a la aplicación como env, por lo que el almacén puede cambiar.
8. Eres dueño de la zona DNS (Cloudflare). Cada proveedor es un destino CNAME. Nada apunta a los servidores de nombres de un proveedor.
9. Las claves de almacenamiento de objetos y el diseño de buckets son los mismos en R2 y S3; el código usa el SDK de S3 con una configuración de endpoint.
10. Cada capa tiene una exportación documentada: pg_dump y replicación lógica para la base de datos, rclone para objetos, nunca se necesita un volcado de Redis porque la caché es desechable y la cola se drena.
11. Los endpoints de salud, el apagado graceful en SIGTERM y la falta de estado horizontal existen desde el día uno, porque cada plataforma, desde Railway hasta Kubernetes, depende de ellos.
12. La telemetría y los registros son OpenTelemetry y JSON desde el día uno; los agentes de proveedor no se instalan en el código.

Niveles

Tres niveles por capa. Los desencadenantes son medibles; la tabla completa con proveedores, costo y las reglas de selección está en references/providers-and-tiers.md.

• Nivel 1, MVP: proveedores administrados que se configuran en minutos y cuestan menos de unos $150 al mes en total. Frontend en Vercel, contenedor backend en Railway, Postgres en Supabase, Redis en Railway, objetos en R2, edge en Cloudflare, Sentry y Better Stack. Hasta que haya clientes de pago que pregunten por el tiempo de actividad, o los números a continuación.
• Nivel 2, Crecimiento: la misma forma en tu propia cuenta de nube donde importa: Postgres en RDS o Aurora Multi AZ con PgBouncer o RDS Proxy, contenedores en ECS Fargate o un EKS pequeño, ElastiCache, S3 o R2, Terraform para todo, una réplica de lectura, Temporal para flujos de trabajo. Desencadenante: un cliente de pago solicita un SLA o SOC 2, o 5k usuarios activos mensuales sostenidos con CPU de base de datos por encima del 60 %, o la factura de PaaS supera los $500 al mes, o se une un segundo ingeniero.
• Nivel 3, Escala: lo que ejecutan Shopify y Notion. Kubernetes con autoescalado, primario fragmentado o particionado, Kafka como columna vertebral de eventos, almacén de datos por CDC, lecturas multirregión, Datadog o Grafana, un equipo de plataforma. Desencadenante: 1000 solicitudes por segundo sostenidas, un primario cerca de 1 TB o limitado por escritura después de réplicas y almacenamiento en caché, un requisito multirregión, o existe un equipo de operaciones para ejecutarlo.

Mover niveles es por capa, no todo a la vez. La base de datos generalmente se mueve primero, luego el backend, y el frontend al final, porque el frontend es lo más barato de dejar donde está.

Orden de construcción

1. Esquema, migraciones, roles, RLS (references/database.md, references/security.md).
2. Verificación de identidad y middleware de contexto de inquilino.
3. Rutas principales de API con validación e idempotencia en escrituras.
4. Middleware de limitación de velocidad y almacenamiento en caché (references/rate-limiting.md, references/caching.md).
5. Worker y colas; cualquier cosa lenta o externa sale de la ruta de solicitud (references/jobs-and-queues.md).
6. Frontend contra la API.
7. Móvil contra la misma API.
8. Registros, métricas, trazas, comprobaciones de salud, alertas (references/observability-and-reliability.md).
9. Puerta de lanzamiento, prueba de carga a tres veces el pico esperado, una prueba de restauración (references/launch-checklist.md).

Plantilla de PLAN.md

# <Proyecto> Plan
## Producto en tres oraciones
## Usuarios, inquilino, roles
## Proveedores por capa         (nivel por capa, por qué, el desencadenante que lo mueve, desde providers-and-tiers.md)
## Modelo de datos              (tablas, tenant_id marcado, índices, tablas particionadas)
## Superficie de API            (rutas por recurso, nivel de autenticación, nivel de límite de velocidad)
## Trabajos en segundo plano    (cola, desencadenante, clave de idempotencia, política de reintentos)
## Terceros                     (servicio, propósito, nombre del secreto, límite, modo de fallo)
## Mapa de caché                (qué, clave, TTL, qué escrituras lo invalidan)
## Modelo de amenazas           (los 5 principales casos de abuso y el control para cada uno)
## Supuestos de escala          (usuarios, filas, solicitudes por minuto en el lanzamiento y a 10x)
## Costo en el lanzamiento      (por proveedor, por mes)
## Plan de salida por proveedor (el playbook de migrations.md que se aplica, en una línea cada uno)
## Diagrama

Reglas no negociables

1. Cada tabla propiedad de un inquilino tiene tenant_id; RLS habilitado y forzado; la API establece el inquilino por transacción basado en membresía verificada, nunca desde la entrada de la solicitud.
2. Los clientes nunca tocan la base de datos ni tienen claves privilegiadas. Todo pasa a través de la API.
3. Cada entrada validada en el límite con claves desconocidas rechazadas; cada consulta parametrizada.
4. La API y los workers se conectan a través de un pooler con grupos pequeños; tiempos de espera de declaración establecidos por rol.
5. Límites de velocidad en el edge y en la API, claveados por usuario, inquilino e IP. Claves de caché con ámbito de inquilino y versionadas.
6. Secretos en el almacén de la plataforma, un conjunto por entorno, nunca en git o en un paquete móvil. Producción y staging son proyectos y cuentas separados.
7. PITR activado y una restauración probada una vez.
8. Firma de webhooks verificada, protección contra repetición, idempotente, respondida en menos de dos segundos.
9. Tiempos de espera en cada llamada saliente; reintentos con jitter solo en trabajos idempotentes; trabajos fallidos visibles para un humano.
10. ID de solicitud e ID de inquilino en cada línea de registro; alertas sobre tasa de error, latencia p95, conteo 5xx, antigüedad de cola, trabajos fallidos, conexiones de base de datos.

Móvil

1. Aplicación existente de React Native o Expo: se queda.
2. Aplicación nueva, solo iOS o iOS primero: Swift nativo y SwiftUI. Las grandes empresas se volvieron nativas en 2026 (Shopify de vuelta a Swift y Kotlin, Notion a SwiftUI) porque los agentes de codificación eliminaron el costo del segundo código base; lo mismo se aplica para un equipo pequeño. Kotlin solo cuando Android se construye realmente.
3. Aplicación nueva que debe lanzar iOS y Android el mismo día con una o dos personas: Expo.
4. De cualquier manera, la aplicación se comunica solo con la API, guarda tokens en almacenamiento seguro y no envía nada secreto en el paquete.

Archivos de referencia

• references/providers-and-tiers.md: la tabla por capa (práctica de grandes empresas, proveedores de nivel 1, 2, 3, desencadenante, costo) y las reglas de selección que convierten una descripción de proyecto en opciones.
• references/migrations.md: el manual paso a paso para mover cada capa a un nivel superior.
• references/architecture.md: el diagrama con etiquetas de nivel, las tres rutas de solicitud, diseños de repositorio, entornos, configuración de edge y plataforma.
• references/security.md: tenencia y RLS, identidad, secretos, encabezados, entrada, cargas, webhooks, cifrado, eliminación y exportación, móvil, registro de auditoría, incidentes.
• references/rate-limiting.md: cuatro capas con números y el middleware.
• references/caching.md: cada capa de caché, esquema de claves, TTL, invalidación, protección contra estampida.
• references/database.md: reglas de esquema, roles, pooling.

… [truncado para traducción]