Por qué WebBlocks CMS es un paquete Composer

Cuando un producto Laravel existente necesita páginas, navegación, medios, localización y un flujo de trabajo editorial, la primera pregunta a menudo se formula como: ¿debería el CMS ser parte de la aplicación o un servicio independiente?

Ese encuadre omite una útil opción intermedia. Un CMS puede ejecutarse dentro de la aplicación Laravel sin convertirse en la aplicación en sí.

WebBlocks CMS se distribuye como el paquete Composer fklavyenet/webblocks-cms. La elección tiene menos que ver con la conveniencia de la instalación que con la propiedad. El paquete aporta un sistema de contenidos; el host sigue siendo el producto Laravel.

La instalación del paquete no entrega la raíz del proyecto al CMS. El host sigue siendo propietario de su programa de arranque, entorno, conexión de base de datos, caché, colas, correo, tareas programadas, implementación, copias de seguridad, raíz de documentos públicos y código específico del producto.

También es dueño de su dominio. Una plataforma de aprendizaje mantiene sus cursos y estudiantes. Una aplicación de comercio mantiene sus pedidos y clientes. El CMS puede publicar páginas de marketing o documentación junto a esas características, pero no debe convertir conceptos de host en conceptos de CMS simplemente porque ambos se ejecutan en un solo proceso.

Por eso son importantes los espacios de nombres. WebBlocks utiliza /webadmin; no supone que el /admin del host pertenezca al CMS. Los activos de CMS estáticos utilizan /cms. Los nombres de rutas, vistas, claves de configuración, tablas y autorizaciones necesitan una propiedad igualmente clara.

Laravel descubre el proveedor de servicios de paquetes a través de Composer. El paquete registra sus rutas, vistas de espacios de nombres, traducciones, migraciones, valores de configuración predeterminados, comandos, políticas y activos estáticos.

El resultado es un conjunto sustancial de funciones (páginas, diseños, bloques, medios, localización, revisiones, Shared Slots, navegación, API de contenido y la interfaz del operador) sin copiar controladores y modelos de CMS en el directorio app/ del host.

Esto es importante durante las actualizaciones. El código propiedad del paquete tiene una ubicación canónica. Un archivo CMS eliminado puede desaparecer con un reemplazo de paquete en lugar de permanecer como una antigua anulación de nivel raíz. Los archivos de host y los archivos de paquete pueden seguir diferentes ciclos de vida de lanzamiento porque la propiedad es explícita.

Un servicio headless compra un aislamiento real. Puede escalar, implementarse y fallar de forma independiente, y múltiples productos pueden consumirlo en todas las pilas de tecnología. Cuando esas propiedades son requisitos, un límite HTTP puede ser el correcto.

También crea trabajo de integración. La autenticación, la autorización, las vistas previas, el enrutamiento localizado, el acceso a los medios, la invalidación de la caché, la coordinación de la implementación y el manejo de fallas cruzan los límites de la red. El contenido que necesita datos de la aplicación normalmente requiere otra API o capa de sincronización.

Un paquete hace un comercio diferente. Reutiliza el tiempo de ejecución Laravel del host y puede participar en las mismas transacciones, políticas, enrutamiento e implementación. Para un producto Laravel con un propietario operativo, ese puede ser un límite más simple.

La separación operativa debería amortizarse por sí sola. Un servicio de red no está automáticamente más desacoplado cuando cada flujo de trabajo útil todavía depende de un vínculo personalizado entre el servicio y el producto.

El embalaje Composer tiene costes reales. El CMS y el host comparten un proceso PHP, un solucionador de dependencias, una versión Laravel y un servidor de base de datos. Las rutas, el middleware, la configuración, las tablas, los supuestos de autenticación y las rutas públicas pueden chocar si los límites se diseñan descuidadamente.

La propiedad del esquema también necesita disciplina. Las migraciones de paquetes pueden crear tablas CMS, pero no deben inferir la propiedad de una tabla de host existente porque un nombre coincide. Las instalaciones parciales necesitan detección y reparación explícita, no conjeturas destructivas.

Los usuarios son un buen ejemplo. Un host compartido puede usar una tabla users para la identidad, mientras que el acceso al CMS está representado por roles de CMS y asignaciones de sitios. Un administrador de host no es automáticamente un superadministrador de CMS y lo contrario también ocurre. La reutilización de la identidad no debe colapsar dos sistemas de autorización.

Estos no son argumentos en contra del modelo de paquete. Son el trabajo necesario para hacerlo realidad.

Una prueba práctica detecta muchos errores de arquitectura: imagine instalar el paquete en un producto Laravel no relacionado.

¿Vería una ruta, ruta de recurso, dominio, registro inicial o definición de aplicación que pertenezca únicamente al host original? ¿El CMS requeriría que el host adopte su URL de administrador o su cadena de compilación de interfaz? ¿Una actualización sobrescribiría el contenido o la configuración propiedad del sitio?

Si la respuesta es sí, la característica probablemente cruzó el límite del paquete.

WebBlocks aplica la misma regla a las aplicaciones ejecutables. El núcleo de CMS proporciona un modelo genérico de registro y permisos; Las definiciones reales de la aplicación host pertenecen a la base de datos o al repositorio de esa instalación. El paquete no debe introducir de contrabando las convenciones del sistema de archivos de un cliente en cada consumidor.

Instalar con Composer se convierte en una promesa arquitectónica solo cuando la propiedad queda clara después de la instalación:

• el host es propietario de la aplicación y las operaciones Laravel;
• el paquete posee un código de producto CMS reutilizable;
• el contenido del sitio y las anulaciones pertenecen a la instalación;
• los datos del dominio del host siguen siendo datos del dominio del host;
• la autenticación se puede compartir mientras la autorización permanece dentro del alcance;
• la capacidad de publicación no se convierte silenciosamente en autoridad de implementación.

Esa promesa es la razón por la que WebBlocks CMS es un paquete. El objetivo no es hacer que todas las aplicaciones Laravel se parezcan a WebBlocks. Se trata de añadir una publicación estructurada a una aplicación que debería seguir siendo reconocible como propia.

Elija un servicio independiente cuando las operaciones independientes, la reutilización entre pilas o el aislamiento de seguridad justifiquen los límites de la red. Elija un paquete cuando el contenido y el producto necesiten una estrecha integración y un tiempo de ejecución Laravel sea una ventaja más que una desventaja.

¿Qué responsabilidades necesitas separar y cuáles se vuelven más difíciles cuando lo haces?