Cuándo Laravel es la elección equivocada

Vendemos ingeniería Laravel. Es una razón para desconfiar de un artículo como este y también una razón para escribirlo: la versión cara de esta conversación es la que ocurre dos años después, y preferimos tenerla ahora.

Laravel es un valor por defecto muy bueno para una aplicación web con una base de datos detrás. Esto es donde no lo es.

1. El trabajo es sobre todo cálculo, no sobre todo espera

Procesamiento de imagen y vídeo, trabajo numérico a gran escala, entrenamiento o inferencia de modelos, cualquier cosa que mantenga un núcleo ocupado durante segundos.

PHP no es mal lenguaje para calcular, pero el modelo de un proceso por petición significa que un trabajo pesado ocupa un worker durante toda su duración. Métalo en una cola y lo habrá movido, no resuelto: ahora necesita una flota de workers dimensionada para el trabajo más pesado.

Lo que funciona es Laravel como aplicación, con el paso pesado corriendo donde corresponde y comunicado como servicio. Lo que no funciona es intentar que PHP sea la capa de cómputo.

2. Miles de conexiones persistentes

Un chat, edición colaborativa en vivo, un servidor de juego, un feed de cotizaciones: cualquier cosa donde los clientes mantengan una conexión abierta y reciban envíos.

El modelo es un proceso por petición. Las conexiones de larga vida son la forma contraria, y aunque hay maneras de añadirlo, estará trabajando contra el entorno de ejecución en lugar de con él. Un servidor de tiempo real dedicado al lado de su aplicación Laravel es la disposición que funciona, y además es a la que va a llegar de todas formas.

Fíjese en el límite, porque importa: las notificaciones ocasionales enviadas a un navegador están bien y están bien soportadas. Es la difusión sostenida a gran volumen lo que no pertenece aquí.

3. Garantías duras de latencia

Por debajo del milisegundo, de forma constante, en el percentil noventa y nueve. Pujas publicitarias, datos de mercado, ingesta de telemetría a tasas muy altas.

Arrancar un framework por petición - incluso uno rápido, incluso con caché de opcode - no es cómo se llega a ese presupuesto. Un entorno de larga ejecución elimina el arranque, y en ese punto le está pidiendo a PHP que sea algo para lo que no fue diseñado cuando varios otros lenguajes ya lo son.

4. No hay capa web en absoluto

Una herramienta de línea de comandos, una aplicación de escritorio, un demonio, una biblioteca que instalarán otros desarrolladores. Laravel trae un kernel HTTP, una capa de enrutado, un contenedor configurado para una aplicación web y una estructura de directorios con forma de sitio. Si no se usa nada de eso, es peso sin beneficio.

Para una herramienta de consola, los componentes de consola de Laravel están disponibles por separado. Para una biblioteca, una biblioteca.

5. El equipo no escribe PHP

Un equipo de tres personas fuertes en otro lenguaje y que nunca ha entregado PHP producirá una aplicación mejor en lo que conoce. La calidad del framework es un factor menor que la fluidez, y no está cerca.

El caso contrario es la contratación: si espera hacer crecer el equipo, el mercado de PHP y Laravel es grande y la incorporación es corta. Ese es un argumento real para elegirlo a propósito, pero es un argumento sobre dieciocho meses vista, no sobre este trimestre.

6. Ya existe un producto que lo hace

El más común, y el que más cuesta cuando se ignora. Una tienda con catálogo simple, un blog, una página de reservas, un formulario interno.

El software a medida es un pasivo que mantiene para siempre. Una plataforma es una suscripción que puede cancelar. Construir debería empezar cuando la plataforma sea demostrablemente lo que le está costando dinero, que es un punto reconocible y no una sensación.

Dónde la respuesta es sí

Una aplicación web con base de datos relacional, usuarios con roles, trabajo en segundo plano, integraciones con terceros, una parte de administración, y un equipo que cambiará con los años. Eso es la mayor parte del software de negocio, y Laravel es genuinamente excelente en ello.

El framework no decide si esa aplicación sobrevive. Lo deciden el esquema, si los trabajos se pueden ejecutar dos veces sin daño, si alguien vigila la cola, y si las pruebas se darían cuenta de una regresión. Una aplicación que acierta en eso es mantenible en Laravel y en cualquier otra cosa. Una que falla en eso no la salva el lenguaje en que está escrita.

Esta página responde la pregunta general. Si ya lo ha reducido a dos candidatos, la comparación concreta es mejor lectura: Symfony cuando la discusión es cuánta arquitectura quiere que le den hecha, Rails si la lista corta son dos frameworks full-stack con opinión, Django cuando el otro lenguaje del equipo es Python, y Node cuando lo que construye es una API y nada más.

El caso que esta página no cubre es aquel en el que el producto es contenido y no comportamiento. Ahí la alternativa no es otro framework, y la comparación que merece leerse es WordPress, donde nuestra respuesta es más veces que no que se quede donde está.