¿Se ha abandonado la filosofía Unix en el diseño de aplicaciones web? [cerrado]

La filosofía de Unix fomenta el uso de pequeños programas de cooperación genéricamente reutilizables que colaboran con formas de comunicación entre procesos como tuberías, quince, enchufes, en oposición al espacio de memoria compartida y el enlace. Los programas MH y uzbl a menudo se dan como ejemplos de aplicaciones que ejemplifican la filosofía de Unix en su diseño.

Si este es el caso, ¿no es cierto que la filosofía de Unix ha sido totalmente abandonada en el diseño de aplicaciones web? Casi todas las aplicaciones web que procesan solicitudes ahora se crean como procesos monolíticos grandes de larga duración que manejan todo el ciclo de solicitud / respuesta (aparte de las llamadas a un programa de base de datos externo) no solo para un recurso, sino para todos los recursos en todo un dominio.

¿Esto se debe principalmente a que canalizar una colección de programas externos para construir una respuesta dinámica a una solicitud web tiene demasiada sobrecarga en el tiempo de inicio del proceso? Puedo ver cómo es este el caso si desea canalizar los scripts de Ruby o Python, pero tal vez si usa un lenguaje como Haskell que puede compilar, ¿desaparecerán los obstáculos reales para seguir la filosofía de Unix en la creación de aplicaciones web?

Creo que depende bastante de dónde trazas un límite entre las aplicaciones (es decir, cuál es tu definición de aplicación) y qué casos de uso tienes en cuenta.

Si bien podría implementar un navegador web como una fusión de wget/ curl, un analizador HTML / XML que llamaría una aplicación simple para cada nodo del documento, un motor de JavaScript independiente que interactuaría con todo esto y un visualizador "simple" que "simplemente" colocar el resultado de lo anterior en la pantalla (y devolver las entradas a algún proceso de coordinación central) sería aún más complicado que (probablemente cualquier) otro navegador de hoy.

En cuanto a canalizar los datos a un proceso externo, así es como realmente comenzó . Si le preocupa el tamaño de un código de aplicación web promedio, sí, a menudo son grandes (y a menudo porque son una capa situada sobre una plataforma escrita en un lenguaje de programación interpretado en lugar de una aplicación "simple"), pero compárelo a sus equivalentes. Clientes de correo electrónico, suites de oficina ... lo que sea. Todos estos son bastante complejos y tienen demasiada funcionalidad para implementarse como un par de procesos que se comunican a través de tuberías. Para las tareas para las que está utilizando estas aplicaciones, a menudo también son complejas. No hay buenas soluciones simples para problemas complejos.

Tal vez sea hora de mirar un poco más allá de la motivación detrás del lema de UNIX "aplicaciones que funcionan un poco pero son buenas en eso". Reemplace las "aplicaciones" con "unidades modulares generales" y llegará a una de las buenas prácticas básicas de programación: haga las cosas de forma modular, de modo que las piezas puedan reutilizarse y desarrollarse por separado . Eso es lo que realmente importa, en mi humilde opinión (y la elección del lenguaje de programación tiene muy poco que ver con eso).

ps (siguiendo el comentario) : en el sentido más estricto, en su mayoría tiene razón: las aplicaciones web no siguen la filosofía de UNIX (de dividirse en varios programas independientes más pequeños). Sin embargo, todo el concepto de lo que es una aplicación parece bastante turbio: sedprobablemente podría considerarse una aplicación en algunas situaciones , mientras que generalmente actúa solo como un filtro.

Por lo tanto, depende de cuán literalmente quieras tomarlo. Si utiliza la definición habitual de un proceso: algo que se ejecuta como un proceso único (en el sentido en que lo ve el núcleo), entonces, por ejemplo, una aplicación web PHP interpretada en httpd por un módulo es exactamente lo contrario. ¿Las bibliotecas compartidas cargadas todavía caen dentro del alcance de un solo proceso (porque usan el mismo espacio de direcciones) o ya están algo más separadas (inmutables desde el punto del programador, completamente reutilizables y se comunican a través de una API bien definida)?

Por otro lado, la mayoría de las aplicaciones web hoy en día se dividen en partes de cliente y servidor, que se ejecutan como procesos separados, generalmente en diferentes sistemas (e incluso hardware físicamente separado). Estas dos partes se comunican entre sí a través de una interfaz bien definida (generalmente textual) (XML / HTML / JSON sobre HTTP). A menudo (al menos en el navegador) hay varios subprocesos que procesan el lado del cliente de la aplicación (JavaScript / DOM, entrada / salida ...), a veces incluso un proceso separado que ejecuta un complemento (Java, Flash, ... ) Eso suena exactamente como la filosofía original de UNIX, especialmente en Linux, donde los hilos son procesos de (casi) cualquier cuenta.

Además de eso, las partes del servidor se dividen casi siempre en varias partes distintas: un motor de base de datos separado que realiza operaciones solicitadas en datos estructurados (o no estructurados) es un ejemplo canónico. Simplemente no tiene mucho sentido integrar una base de datos en un servidor web. Sin embargo, tampoco tiene mucho sentido dividir una base de datos en varios procesos que se especializarían en, por ejemplo, analizar solo solicitudes, recuperar datos del almacenamiento de datos, filtrar los datos ... Uno tiene que encontrar el equilibrio entre crear un gigante omnipotente y un Enjambre de trabajadores casi nulos que pasan la mayor parte del tiempo hablando entre ellos.

En cuanto a la interfaz de texto : tenga en cuenta que lo que era cierto para los datos procesados ​​hace 40 años no es necesariamente cierto hoy en día: los formatos binarios son más baratos tanto en espacio como en potencia para la deserialización y la cantidad de datos es inmensamente mayor.

Otra pregunta importante también es, ¿cuál ha sido realmente el objetivo de la filosofía UNIX? No creo que hayan existido simulaciones numéricas, sistemas bancarios o galerías de fotos / redes sociales de acceso público. Sin embargo, el mantenimiento de los sistemas que ejecutan estos servicios definitivamente ha sido y probablemente lo será en el futuro.

No estoy seguro de que la filosofía de Unix haya estado presente alguna vez en el diseño de aplicaciones web; sin embargo, aunque puede ser cierto que muchas aplicaciones web se comportan de la manera que usted ha descrito, uno podría considerar que las aplicaciones web en estos días tienen más probabilidades de ser consumidores de datos (dado el método cada vez más orientado a la API / servicio web para producir datos para el consumo web).
Esto a su vez puede verse que fomenta el uso de componentes pequeños y reutilizables (en forma de funciones de JavaScript) que colaboran entre sí, por lo que puede existir un pequeño paralelismo.