En el artículo anterior, diseñamos un esquema completo para nuestra API de red social. Definimos tipos para Usuario, Publicacion y Comentario, estructuramos nuestras queries y mutations, y creamos un contrato claro de lo que nuestra API puede hacer.
Pero ese esquema está solo en un archivo en tu computadora. Hoy vamos a cambiar eso.
En este artículo, vas a desplegar tu esquema en AWS AppSync (un servicio administrado de GraphQL) y verlo funcionando en vivo. Al final, tendrás:
- ✅ Una API de GraphQL desplegada en la nube
- ✅ Un endpoint que puedes compartir
- ✅ Documentación generada automáticamente
- ✅ Un playground para probar queries
Y lo mejor: lo haremos en menos de 10 minutos, sin escribir código de backend.
Antes de empezar
Para seguir este tutorial necesitas:
- Tu archivo
schema.graphqldel artículo anterior - Una cuenta de AWS (el free tier es suficiente)
- Un navegador web
¿No tienes cuenta de AWS? No te preocupes, crearla es gratis y toma solo unos minutos. Ana Cunha escribió una guía completa sobre cómo empezar con AWS sin gastar nada que te explica todo sobre el Free Tier.
Parte 1: Entendiendo tus opciones
Antes de desplegar, hablemos brevemente de las diferentes maneras de correr una API de GraphQL. No vamos a profundizar en cada una, pero es importante que sepas qué opciones existen.
Opciones self-hosted (tú manejas el servidor)
Apollo Server y GraphQL Yoga son las opciones más populares. Tú instalas el servidor, lo configuras, y lo despliegas donde quieras (AWS, Google Cloud, tu propia computadora, etc.).
Ventajas:
- Control total sobre todo
- Puedes correrlo en cualquier lugar
- El software es open source y gratuito
Desventajas:
- Tú manejas el servidor, las actualizaciones, el escalamiento
- Necesitas conocimientos de DevOps
- Más tiempo de setup
- Pagas por la infraestructura donde lo despliegues
Opciones managed o serverless (alguien más maneja el servidor)
En este caso, un proveedor de nube (como AWS, Google Cloud, etc.) se encarga de toda la infraestructura por ti. Tú solo te enfocas en tu código y lógica de negocio.
AWS AppSync, Hasura, y Stepzen son servicios que manejan toda la infraestructura por ti. Tú solo subes tu esquema y defines tu lógica.
Ventajas:
- Sin servidores que mantener
- Escalamiento automático
- Features incluidos (real-time, caching, etc.)
Desventajas:
- Menos control
- Dependes del proveedor
- El modelo de precios varía según el proveedor (revisa la documentación de precios de cada servicio para tu caso específico)
¿Por qué AppSync para esta serie?
Elegimos AWS AppSync por tres razones:
- Serverless - No tienes que preocuparte por servidores
- Perfecto para aprender - Te enfocas en GraphQL, no en infraestructura
- Real-time incluido - Lo usaremos en un próximo artículo para subscriptions
💡 Tip importante: No existe una opción "mejor" para todos los casos. AppSync es excelente tanto para aprender como para producción. Tu elección entre opciones self-hosted o managed dependerá de tus necesidades específicas de control, experiencia del equipo y preferencias de arquitectura.
Parte 2: ¿Qué es AWS AppSync?
Como mencioné brevemente, AWS AppSync es un servicio administrado de GraphQL. Ahora veamos con más detalle qué significa esto y qué hace por ti.
Piénsalo como un "GraphQL-as-a-Service": tú defines el esquema y la lógica, AppSync maneja todo lo demás.
Lo que AppSync hace por ti
- Hosting del esquema - Tu esquema vive en la nube, siempre disponible
- Ejecución de queries - Procesa las queries que llegan a tu API
- WebSockets para real-time - Subscriptions funcionan automáticamente
- Caching - Respuestas más rápidas sin configuración extra
- Endpoint de API - Una URL que tus clientes pueden usar
Lo que tú controlas
- Tu esquema - Defines qué datos existen y cómo se relacionan
- Tus resolvers - La lógica que obtiene los datos (lo haremos en el artículo 4)
- Cómo retornas datos - Usaremos mock data para aprender
El flujo de trabajo con AppSync
Hoy nos enfocaremos en los pasos 1 y 2. Los resolvers los dejamos para el siguiente artículo.
Parte 3: Desplegando tu esquema
Ahora sí, manos a la obra. Vamos a desplegar tu esquema paso a paso.
Paso 1: Abre la consola de AWS AppSync
- Ve a https://console.aws.amazon.com/appsync
- Si te pide iniciar sesión, usa tu cuenta de AWS
- Asegúrate de estar en la región que prefieras (yo uso
us-east-1)
¿Primera vez en AWS? La interfaz puede parecer abrumadora, pero no te preocupes. Solo vamos a usar AppSync, nada más.
Paso 2: Crea tu API
- Haz clic en el botón naranja "Create API"
- Verás dos opciones: GraphQL API y Events API. Selecciona "GraphQL API"
- Ahora verás una sección llamada "API type" con dos opciones:
- GraphQL APIs ← Selecciona esta
- Merged APIs
- Después de seleccionar "GraphQL APIs", verás opciones de templates. Selecciona "Design from scratch"
- Haz clic en "Next"
- 💡 ¿Por qué GraphQL API y no Events API? Events API es para casos de uso específicos de eventos. Nosotros queremos una API de GraphQL tradicional.
- 💡 ¿Por qué GraphQL APIs y no Merged APIs? Merged APIs es para combinar múltiples APIs en una sola. Como estamos empezando, queremos una API simple.
- 💡 ¿Por qué "Build from scratch"? Porque ya tenemos nuestro esquema del artículo anterior. Las otras opciones son templates que AppSync ofrece, pero nosotros queremos usar el nuestro.
Paso 3: Configura tu API
Ahora verás un formulario con varias secciones. Vamos paso a paso:
Sección 1: API details
API name: Social-Media-API (o el nombre que prefieras)
¿Qué poner en API name? Usa algo descriptivo. Este nombre solo lo verás tú en la consola, no afecta el funcionamiento de tu API.
Deja todo lo demás como está y haz clic en "Next".
Sección 2: Specify GraphQL resources
Aquí AppSync te pregunta si quieres conectar una fuente de datos ahora o después. Verás un mensaje que dice:
"Your API can connect to one or more data sources like Amazon DynamoDB, Amazon OpenSearch, Amazon Aurora, AWS Lambda, Amazon EventBridge, or any HTTP API. You can add your data source later or optionally use this step to generate a GraphQL type backed by a DynamoDB table."
Vamos a elegir Create GraphQL resources later ya que nosotros tenemos nuestro esquema diseñado del artículo anterior. No necesitamos que AppSync genere uno por nosotros. Además, en esta serie usaremos mock data, no DynamoDB.
Haz clic en "Next".
Sección 3: Review and create
Ahora verás un resumen de todo lo que configuraste:
- API type: GraphQL APIs
- API name: Social-Media-API
- GraphQL resources: Create later
Revisa que todo esté correcto y haz clic en "Create API".
¡Felicidades! Acabas de crear tu primera API de GraphQL en AppSync. Ahora vamos a subirle el esquema.
Paso 4: Sube tu esquema
Ahora estás en el dashboard de tu API. Verás dos secciones principales con información sobre los próximos pasos.
- En el menú lateral izquierdo, haz clic en "Schema"
- Verás un editor de texto grande con algunos comentarios por defecto. Aquí es donde va tu esquema.
- Abre tu archivo
schema.graphqldel artículo anterior - Borra los comentarios que están por defecto en el editor de AppSync
- Copia todo el contenido del archivo
- Pégalo en el editor de AppSync
- Haz clic en el botón naranja "Save Schema" en la esquina superior derecha
💡 ¿Qué pasa si ves errores? AppSync valida tu esquema automáticamente. Si hay algún error de sintaxis, te lo mostrará en rojo. Revisa que hayas copiado todo el esquema correctamente.
- Si todo está bien, verás un mensaje de confirmación: "Schema saved successfully"
¡Excelente! Tu esquema ya está desplegado en la nube. AppSync lo validó, lo procesó, y ahora está listo para usarse.
Parte 4: Explorando tu API desplegada
Ahora que tu esquema está en AppSync, vamos a explorar qué generó automáticamente para ti.
Tu endpoint de API
- En el menú lateral, haz clic en "Settings"
- Busca la sección "API URL" o "GraphQL endpoint"
- Verás una URL que se ve algo así:
https://xxxxxxxxxx.appsync-api.us-east-1.amazonaws.com/graphql
Esta es la URL de tu API. Cualquier cliente de GraphQL puede usarla para hacer queries y mutations. Por ahora, solo tú tienes acceso (hablaremos de autenticación en futuros artículos).
Documentación auto-generada
Volvamos a explorar algo increíble de GraphQL: la documentación se genera automáticamente desde tu esquema.
- En el menú lateral, haz clic en "Queries"
- Verás un editor de queries (lo usaremos en un momento)
- En la esquina superior derecha del editor, busca un botón o ícono que diga "Docs" o tenga un símbolo de libro 📖
- Haz clic en "Docs" y se abrirá un panel lateral
¿Qué ves aquí?
- Todos tus tipos:
Usuario,Publicacion,Comentario - Tus queries:
usuario,publicacion,publicaciones - Tus mutations:
crearUsuario,crearPublicacion,crearComentario - Los campos de cada tipo con sus tipos de datos
Esto es introspección en acción. GraphQL permite que cualquier cliente "pregunte" sobre el esquema. Así es como herramientas como este playground saben qué campos existen y pueden darte autocompletado.
Explorando un tipo
En el panel de documentación:
- Haz clic en el tipo "Usuario"
- Verás todos sus campos:
id,nombre,email,fotoPerfil,publicaciones,creadoEn - Nota que cada campo muestra su tipo:
String!,[Publicacion!]!, etc.
¿Por qué esto es importante?
- No necesitas documentación separada que se desactualice
- El esquema ES la documentación
- Cualquier cambio en el esquema se refleja inmediatamente aquí
- Los desarrolladores que usen tu API pueden explorarla sin preguntarte
Parte 5: ¿Qué sigue?
Has llegado lejos. Veamos qué tienes ahora y qué nos falta.
Lo que ya tienes ✅
- Esquema desplegado - Tu contrato de API está en la nube
- Endpoint de API - Una URL que los clientes pueden usar
- Documentación automática - Generada desde tu esquema
- Playground para probar - El editor de queries está listo
Lo que nos falta ⏳
- Resolvers - La lógica que retorna datos
-
Datos para consultar - Por ahora, las queries retornarían
null
¿Por qué no probamos queries ahora?
Porque sin resolvers, todas las queries retornarían null o errores. Sería como tener un restaurante con menú pero sin cocina. El menú (esquema) está listo, pero necesitamos la cocina (resolvers) para servir comida (datos).
En el próximo artículo
En la Parte 4 de esta serie, vamos a:
- Entender qué son los resolvers - El puente entre tu esquema y tus datos
- Implementar resolvers con TypeScript - Código con type safety
- Usar mock data - Datos de prueba para ver resultados inmediatos
- Probar queries reales - Ver tu API funcionando de verdad
- Implementar mutations - Crear usuarios, publicaciones y comentarios
Después de ese artículo, podrás hacer queries como esta y obtener resultados reales:
query {
publicaciones {
contenido
autor {
nombre
}
comentarios {
contenido
}
}
}
Antes del próximo artículo
Te recomiendo:
- Explora la documentación - Familiarízate con el panel de Docs
- Revisa tu esquema - Asegúrate de que tiene todo lo que necesitas
- Guarda tu API endpoint - Lo necesitarás después
Conclusión
Hoy diste un paso importante: llevaste tu esquema de un archivo local a una API desplegada en la nube.
Lo que lograste
- ✅ Entendiste las opciones para correr GraphQL APIs
- ✅ Conociste AWS AppSync y qué hace por ti
- ✅ Creaste tu primera API en AppSync
- ✅ Desplegaste tu esquema
- ✅ Exploraste la documentación auto-generada
El viaje hasta ahora
- Parte 1: Introducción a GraphQL - Entendimos qué es y por qué usarlo
- Parte 2: Diseño del esquema - Creamos nuestro contrato de API
- Parte 3: Deployment (este artículo) - Desplegamos el esquema en AppSync
- Próximo: Implementación de resolvers - Haremos que la API funcione
Tu API está lista para el siguiente paso
Tienes una API de GraphQL desplegada con:
- Un esquema validado
- Documentación automática
- Un endpoint público (protegido por ahora)
- Todo listo para agregar resolvers
En el próximo artículo, le daremos vida a esta API. Implementaremos los resolvers que harán que tus queries y mutations realmente funcionen.
Por ahora, celebra este logro. Pasaste de un archivo de texto a una API en la nube. Eso no es poca cosa. 🚀
Top comments (1)
🙌🏻