Una plataforma de contenido multiinquilino.
Un editor de bloques, un renderizador público, una aplicación de cuenta para usuarios finales y un plano de control, sobre una capa de paquetes compartida. Cuatro superficies que tienen que ponerse de acuerdo sobre un documento, un inquilino y un permiso, que es todo el problema de ingeniería.
Cuatro superficies, una sola verdad.
El usuario edita un documento. Un navegador acaba recibiendo una página. Son artefactos distintos, producidos por código distinto, en momentos distintos, y un constructor es digno de confianza exactamente en la medida en que los mantiene de acuerdo. Una vista previa que se desvía, un deshacer que restaura un estado que el modelo nunca debió permitir, un cambio de plantilla que reescribe en silencio documentos creados con la versión anterior: cada uno es pequeño por separado y, juntos, son la razón por la que la gente abandona un constructor y vuelve a escribir marcado.
El modelo multiinquilino toma ese mismo problema y lo repite en todas las demás dimensiones. Quién puede editar esta página, a qué espacio de trabajo resuelve este dominio personalizado, en qué plan está este espacio de trabajo y si esta clave de API ve algo que no debería ver. Cada una es un lugar donde dos representaciones de un mismo hecho pueden contradecirse.
Así que el trabajo interesante no es la experiencia de edición. Es dónde se permite que viva cada hecho, y si el diseño hace inalcanzable la respuesta equivocada en lugar de simplemente desaconsejarla.
Los requisitos que salieron de ahí.
No es una lista de funcionalidades. Son las propiedades que el sistema tenía que cumplir para que la categoría funcione.
- Un modelo de bloques en el que el editor y el renderizador no puedan divergir
- Cada guardado recuperable, no solo el último
- Permisos decididos en un solo lugar en vez de comprobados en cada punto de llamada
- Un aislamiento entre inquilinos que una cláusula WHERE olvidada no pueda romper
Dónde se obligó a vivir a cada hecho.
Cuatro decisiones que dieron forma a la plataforma, cada una con un contrario defendible que muchos productos eligen.
Presentadas como decisiones y no como funcionalidades, porque cada una tiene un coste. Esto es hacia qué lado se inclinó esta y lo que permitió.
Los bloques se declaran una vez y la unión se genera
Un bloque declara su tipo, su esquema de validación, sus valores por defecto, su editor y su renderizador en una sola definición. Un manifiesto lista los bloques que incluye una compilación, y la generación de código lo convierte en la unión de esquemas contra la que se valida todo lo demás. La alternativa, una unión de tipos mantenida a mano, se desvía la primera vez que alguien añade un bloque y actualiza tres de los cuatro lugares que lo necesitaban.
Cada guardado escribe una versión, no sobrescribe
Guardar añade una fila de versión numerada con una instantánea completa del documento y de sus metadatos, con el autor y la hora. El historial, la comparación y la reversión leen entonces de un registro que ya existe, en lugar de una pila de deshacer que muere con la pestaña del navegador. Cuesta almacenamiento, que es lo más barato de lo que se intercambia aquí.
Los permisos se resuelven en un único motor de reglas
Los roles, las políticas y el despliegue progresivo de funcionalidades se evalúan en un solo lugar en vez de volver a preguntarse en cada punto de llamada. Las comprobaciones dispersas son legibles una a una e imposibles de auditar en conjunto: nadie puede responder qué puede hacer realmente un rol sin leer todas las rutas que lo mencionan.
El aislamiento entre inquilinos es una propiedad del esquema, no una convención
Los espacios de trabajo, las organizaciones, los equipos y el enrutamiento de dominios se modelan como relaciones reales con restricciones reales, de modo que el aislamiento lo garantiza la base de datos y no cada autor acordándose del mismo filtro. El enfoque contrario funciona perfectamente hasta la consulta que se olvida.
La decisión que importó.
Una decisión por proyecto, tomada con una alternativa real sobre la mesa. Aquí se nombra la alternativa, y también lo que costó decidir en su contra.
Un modelo de documento restringido, no un lienzo libre.
El modelo solo permite documentos que el renderizador sabe renderizar. No hay forma de crear en el editor una página que el publicador no pueda servir, porque las formas que producirían una no se pueden expresar.
Es una decisión sobre lo que el producto se niega a hacer, tomada antes de que existiera nada de la experiencia de edición, y es lo que hace asumibles las cuatro decisiones anteriores. La paridad de la vista previa, una salida determinista y unas migraciones compatibles hacia el futuro son abordables sobre un conjunto acotado de formas de documento y abiertas sobre uno que no lo está.
- La alternativa
- Un lienzo libre: posicionamiento absoluto, cualquier elemento en cualquier sitio. Es la forma que venden la mayoría de los constructores y lo primero que pide un autor. Es realmente más fácil de construir, luce más en los primeros cinco minutos y no impone ninguna restricción a quien lo usa.
- Lo que costó
- Expresividad, de forma permanente. Los diseños que permite un lienzo libre no están al alcance aquí, y para algunos de ellos la respuesta honesta es un no en lugar de un apaño. El límite lo encuentran además primero los autores más dispuestos a forzar la herramienta, que son los peores a quienes decepcionar.
- Por qué la contrapartida se sostiene
- En un lienzo libre cada documento es un caso especial, así que la paridad de la vista previa, el comportamiento adaptable y la migración de esquemas se convierten cada uno en un problema por documento sin solución general. Acotar el modelo convierte tres problemas abiertos en tres finitos, y un problema finito se puede cerrar. El coste se paga una vez, en lo que la herramienta no hará. La alternativa lo cobra para siempre, en lo que no puede prometer.
La comparación anterior es un argumento sobre qué fallos hace posibles cada opción, no una prueba de rendimiento. No se ha ejecutado nada contra un conjunto de evaluación fijo, así que no hay ninguna cifra que dar aquí, y nada de lo anterior debe leerse como si la insinuara.
El razonamiento, publicado.
Esta página describe una clase de problema y no un encargo para un cliente. Estos son los textos donde se desarrolla por completo el mismo razonamiento.
- ArtículoCómo diseñar un sistema de diseño pensado primero para el modo oscuroLo que necesita una superficie de creación por debajo: tokens que lleven significado, para que una página publicada y su editor no puedan divergir.
- ArtículoCómo crear herramientas para desarrolladores que no te castiguenValores por defecto, divulgación progresiva y mensajes de error: casi todo lo que separa una herramienta de creación usable de una potente en la que nadie termina una página.
Pregúntanos por cualquiera de ellos.
Los detalles no están en esta página. Pídelos directamente, o envíanos el problema que de verdad necesitas resolver.