A filosofia Unix foi abandonada no design de aplicativos da web? [fechadas]

A Filosofia Unix incentiva o uso de pequenos programas cooperativos genericamente reutilizáveis ​​que colaboram com formas de comunicação entre processos, como pipes, fifos, soquetes, em oposição ao espaço de memória compartilhada e ao vínculo. Os programas MH e uzbl são frequentemente dados como exemplos de aplicativos que exemplificam a filosofia Unix em seu design.

Se for esse o caso, não é verdade que a filosofia Unix foi totalmente abandonada no design de aplicativos da web? Agora, quase todos os aplicativos Web que processam solicitações são criados como processos monolíticos grandes e de longa execução que lidam com todo o ciclo de solicitação / resposta (além de chamadas para um programa de banco de dados externo) não apenas para um recurso, mas todos os recursos em um domínio inteiro.

Isso ocorre principalmente porque o direcionamento para uma coleção de programas externos para construir uma resposta dinâmica a uma solicitação da Web tem um excesso de sobrecarga no tempo de inicialização do processo? Eu posso ver como é esse o caso, se você quiser usar scripts Ruby ou Python, mas talvez se você usar uma linguagem como Haskell que possa compilar, quaisquer obstáculos reais para seguir a Filosofia Unix na criação de aplicativos da Web desaparecerão?

Eu acho que depende muito de onde você define um limite entre aplicativos (ou seja, qual é a sua definição de aplicativo) e quais casos de uso você leva em consideração.

Embora você possa implementar um navegador da Web como uma amálgama de wget/ curl, um analisador HTML / XML que chamaria um aplicativo simples para cada nó do documento, um mecanismo JavaScript independente que interagisse com tudo isso e um exibidor "simples" que "apenas" colocar a saída do exposto acima na tela (e retornar as entradas para algum processo de coordenação principal), seria ainda mais confuso do que (provavelmente qualquer) outro navegador de hoje.

Quanto a canalizar os dados para um processo externo - foi assim que ele realmente começou . Se você está preocupado com o tamanho de um código médio de aplicativo da Web, sim, eles geralmente são grandes (e geralmente porque são uma camada acima de uma plataforma escrita em uma linguagem de programação interpretada em vez de um aplicativo "simples"), mas compare-o aos seus equivalentes. Clientes de e-mail, suítes de escritório ... o nome dele. Tudo isso é bastante complexo e possui muita funcionalidade para ser implementada em alguns processos de comunicação através de pipes. As tarefas para as quais você está usando esses aplicativos também costumam ser complexas. Não existem boas soluções simples para problemas complexos.

Talvez esteja na hora de olhar um pouco além da motivação por trás do lema do UNIX "aplicativos que fazem um pouco, mas são bons nisso". Substitua "aplicativos" por "unidades modulares gerais" e você chega a uma das boas práticas básicas de programação: faça as coisas de forma modular, para que as peças possam ser reutilizadas e desenvolvidas separadamente . Isso é o que realmente importa, IMHO (e a escolha da linguagem de programação tem muito pouco a ver com isso).

ps (após o comentário) : No sentido mais estrito, você está certo - os aplicativos Web não seguem a filosofia UNIX (de serem divididos em vários programas independentes menores). No entanto, todo o conceito do que é um aplicativo parece bastante obscuro - sedprovavelmente poderia ser considerado um aplicativo em algumas situações , enquanto geralmente atua apenas como um filtro.

Por isso, depende de quão literalmente você deseja tomá-lo. Se você usar a definição usual de um processo - algo em execução como um processo único (no sentido em que o kernel o vê), então, por exemplo, um aplicativo Web PHP interpretado no httpd por um módulo é exatamente o oposto. As bibliotecas compartilhadas carregadas ainda se enquadram no escopo de um único processo (porque usam o mesmo espaço de endereço) ou já são algo mais separado (imutável do ponto do programador, completamente reutilizável e se comunicando por meio de uma API bem definida)?

Por outro lado, a maioria dos aplicativos da Web hoje são divididos em partes de cliente e servidor, que estão sendo executadas como processos separados - geralmente em sistemas diferentes (e até mesmo em hardware fisicamente separado). Essas duas partes se comunicam por meio de uma interface bem definida (geralmente em texto) (XML / HTML / JSON sobre HTTP). Frequentemente (pelo menos no navegador), existem vários threads que processam o lado do cliente do aplicativo (JavaScript / DOM, entrada / saída ...), às vezes até um processo separado executando um plug-in (Java, Flash, ... ) Isso soa exatamente como a filosofia original do UNIX, especialmente no Linux, onde os threads são processados por (quase) qualquer conta.

Além disso, as partes do servidor são praticamente sempre divididas em várias partes distintas - o mecanismo de banco de dados separado que executa operações solicitadas em dados estruturados (ou não estruturados) é um exemplo canônico. Simplesmente não faz muito sentido integrar um banco de dados em um servidor web. No entanto, também não faz muito sentido dividir um banco de dados em vários processos que se especializam em, digamos, analisar apenas solicitações, buscar dados do armazenamento de dados, filtrar os dados ... É preciso encontrar um equilíbrio entre criar um gigante onipotente e um enxame de trabalhadores quase sem força que passam a maior parte do tempo conversando entre si.

Quanto à interface textual : observe que o que era verdade para os dados processados ​​40 anos atrás não é necessariamente verdade hoje - os formatos binários são mais baratos tanto no espaço quanto na energia necessária para a des serialização, e a quantidade de dados é imensamente maior.

Outra questão importante também é: qual foi realmente o alvo da filosofia do UNIX? Acho que nunca foram simulações numéricas, sistemas bancários ou galerias de fotos / redes sociais acessíveis ao público. A manutenção dos sistemas executando esses serviços, no entanto, definitivamente tem sido e provavelmente ocorrerá no futuro.

Não tenho certeza se a Unix Philosophy já esteve presente no design de aplicativos da Web - no entanto, embora possa ser verdade que muitos aplicativos da Web se comportam da maneira que você descreveu, pode-se considerar que os aplicativos da Web hoje em dia têm maior probabilidade de serem consumidores de dados (dado o método cada vez mais api / web orientado a serviços de produção de dados para consumo na web).
Por sua vez, isso pode encorajar o uso de componentes pequenos e reutilizáveis ​​(na forma de funções JavaScript) que colaboram entre si; portanto, um pequeno paralelo pode existir.