Separar el plano de control del plano de salida

Una flota como esta no sólo ejecuta servicios: genera artefactos. Cada sitio de comerciante es una aplicación real y desplegada, clonada de una plantilla compartida y horneada con el contenido de ese comerciante. Es tentador tratar un artefacto generado como una extensión de la propia flota, ya que la flota lo construyó, y dejar que se estire hacia los servicios internos por el canal que resulte cómodo porque «total, es código nuestro». Resístete. El sitio generado es un cliente, igual que cualquier otro cliente, y debería parecerlo en el código.

El plano de control es el conjunto de servicios que gestionan la flota. El plano de salida es el código que corre dentro de cada sitio generado. El trabajo del plano de salida es renderizar el negocio de un comerciante. El trabajo del plano de control es hacer funcionar la flota. En cuanto un sitio generado obtiene un canal lateral especial y sin versionar hacia el plano de control porque «vino de nosotros», esa frontera empieza a tener fugas.

Lo que mantiene honesta esa frontera en la práctica es un fichero de configuración normal, incluido en cada sitio generado, en el que ambos lados están de acuerdo:

// config/webplo.php
return [
    'brand' => [
        'name' => 'Example Business',
        'phone' => '(800) 000-0000',
        'address' => 'New York',
        'language' => 'en',
        'locale' => 'en_US',
        'index' => false,
    ],
    'networks' => [
        'facebook' => null,
        'instagram' => null,
    ],
    'colors' => [
        'primary' => '#D97757',
        'variant' => '#ffffff',
    ],
];

Ese es todo el contrato de contenido entre los dos planos. El trabajo del plano de control es saber cómo es el negocio de un comerciante y escribir ese conocimiento en un fichero como este. El trabajo del plano de salida es renderizar un sitio a partir de lo que diga ese fichero; nunca tiene que saber cómo se produjo ese conocimiento, y el plano de control nunca tiene que saber cómo se renderiza. Ninguno de los dos lados se estira más allá del fichero para coger algo que el otro no publicó.

¿Por qué molestarse en trazar esta línea, en lugar de dejar que un sitio generado llame al endpoint interno que resuelva más rápido? Porque «más rápido» hoy es deuda de mantenimiento mañana. Un sitio se clona una vez y luego vive años, desplegado de forma independiente y actualizado a su propio ritmo. Si el código de ese sitio ha aprendido a depender de alguna forma interna de api-server, cada cambio futuro en api-server tiene ahora que considerar cada sitio ya desplegado como un llamante que no puede ver ni coordinar. Mantén pequeña, estable y explícita la superficie de cara al artefacto, y api-server seguirá libre de cambiar todo lo que hay detrás.