El 80% de los Schemas en Sanity Son Técnico Debt desde el Día Uno
Copias el schema de tu último proyecto. Pegas. Modificas cuatro campos. Funciona.
Seis meses después, el cliente quiere un tipo de contenido nuevo. Empiezas a copiar código. Los campos duplicados se multiplican. Cuando necesitas cambiar algo global, editas en cinco lugares distintos.
El problema real no es que Sanity sea flexible. Es que nadie te enseñó a diseñar schemas como un sistema, no como documentos aislados.
Este es el patrón de diseño que separa proyectos que escalan de los que se convierten en legacy antes de llegar a producción.
Por Qué Tus Schemas Se Convierten en Caos
La mayoría de developers trata cada schema como un documento independiente. Defines post.ts, defines author.ts, defines page.ts. Cada uno con sus campos, sus validaciones, sus referencias.
Funciona para proyectos pequeños. Falla en tres escenarios:
1. Contenido que comparte estructura pero no tipo
Un blog post y un artículo del manual tienen título, fecha, imagen principal, cuerpo y autor. Pero son documentos distintos. La solución naive es duplicar campos en ambos schemas.
2. Cambios que deben propagarse a múltiples tipos
Necesitas añadir un campo featured a doce tipos de contenido. Editas doce archivos. Si te olvidas de uno, tienes inconsistencia en producción.
3. Referencias circulares que rompen validación
Un product referencia category, que referencia collection, que referencing product. Sanity no tiene problema con esto a nivel de datos. Pero tu código de frontend se convierte en un mapa de referencias que nadie entiende.
La arquitectura de schemas en Sanity tiene herramientas para resolver esto. Casi nadie las usa.
El Patrón de Objetos Reutilizables
Sanity distingue entre document y object. Un document es un tipo de contenido raíz. Un object es una estructura reutilizable que puedes embeber en múltiples documentos.
Este es el cambio mental más importante: no todo necesita ser un document.
Step 1: Extrae campos comunes a object types
Crea un object type para todo campo que repitas en más de un documento:
Ahora cualquier documento puede incluir SEO sin duplicar lógica:
Step 2: Usa referencias planas, no anidadas
❌ MAL — Anidado profundo
✅ BIEN — Referencia a documento
Las referencias planas permiten editar el autor una vez y ver el cambio en todos los posts. Los objetos anidados duplican datos y rompen la consistencia.
El Patrón de Composición con Fieldsets
Cuando un schema crece, la interfaz del Studio se vuelve difícil de navegar. Sanity tiene fieldsets para agrupar campos visualmente.
Esto organiza la edición en el Studio sin cambiar la estructura de datos. Un editor ve secciones colapsables lógicas en lugar de una lista infinita de campos.
El Patrón de Validation Centralizada
Cada campo puede tener validation rules. Pero cuando necesitas cambiar una regla globalmente (por ejemplo, "todos los slugs deben tener máximo 50 caracteres"), terminas editando múltiples archivos.
La solución es crear validation helpers reutilizables:
Aplícalos en tus schemas:
Cambiar la regla globalmente significa editar un archivo.
El Patrón de Migración Sin Dolor
El mayor miedo al cambiar schemas es romper contenido existente. Sanity tiene una estrategia: nunca borres campos, solo añádelos y désactivalos.
Estrategia de deprecación segura
❌ RIESGO ALTO — Eliminar campo
✅ ENFOQUE SEGURO — Deprecation workflow
hidden mantiene el campo activo en la base de datos para queries legacy, pero no lo muestra a los editores. Puedes hacer migrate data con un script antes de eliminarlo completamente.
Script de migración con Sanity CLI
Este script migra datos de oldCategory (string) a category (reference). Ejecutas, verificas, y luego puedes eliminar el campo sin miedo.
El Patrón de Schemas Modular
La mejor práctica para proyectos que escalan: organza tus schemas en carpetas lógicas y exporta desde un index central.
Añadir un nuevo tipo de contenido significa crear un archivo y añadirlo al array. Sin magia, sin configuración oculta.
Conclusión
La diferencia entre un proyecto Sanity que escala y uno que se convierte en legacy no es el presupuesto ni la complejidad. Es si diseñaste tus schemas como un sistema o como documentos independientes.
Los patterns que funcionan:
→ Object types para campos reutilizables
→ Referencias planas sobre objetos anidados
→ Fieldsets para organizar la interfaz del Studio
→ Validation helpers centralizados
→ Deprecación gradual sobre borrado agresivo
→ Migraciones con scripts, no a mano
Tu próximo schema debería tomar 15 minutos más en diseñarse. Te ahorrará 15 horas cuando el proyecto crezca.
La pregunta no es si necesitas un schema reutilizable. Es si quieres migrar o si quieres escalar.
Artículos relacionados
- Server Components: El Error de Arquitectura que Anula el Rendimiento en Next.js 16
- Patrones de Diseño para Apify Actors: Cómo Construir Extracción de Datos que No Falla en Producción
- Coordinación Multi-Agente: Por Qué los Frameworks de 19K Stars Son Sobreingeniería
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
