Tive mais de uma situação aonde fui obrigado a portar uma aplicação monolític... · depaula

Tive mais de uma situação aonde fui obrigado a portar uma aplicação monolítica pra microserviço em cenário de missão crítica aonde a gente precisava carregar tudo pra "imagem" de até 1MB. Se vc sair do PHP vai ver que isso é problemático tb no Node, a pasta node_modules com o tempo fica enorme. E porque isso? Os ambientes serveless de algumas arquiteturas tem essa limitação.

Eu me tornei agnótisco com tecnologia com o passar do tempo e pra mim faz mais sentido microframeworks por padrão. Fiz o caminho inverso do Eloquent e descobri que ele veio do https://github.com/j4mie/idiorm. o Blade foi substituido pelo https://picocss.com/. Tudo foi portado para microframeworks que faziam algo similar.

A minha lição: graças a Deus algumas pessoas decidiram reinventar a roda e algumas mantiveram os proetos originais simples e leves o suficientes.

Existem casos e casos. Hoje com o ecossistema do Laravel mais maduro concordo em partes com a sua afirmação, mas na época em que nós tinhamos um cenário com com ZF, Yii, e muitas outras frameworks rivalizando, sem falar sobre tecnologias como Adobe Air, React engatinhando e muita coisa rolando simultâneamente com PHP indo pro lado do HipHop (PHPc) do Facebook não era algo óbvio presumir o desfecho.

Prestei serviço pra um grande banco brasileiro que jogou no lixo todo uma ecossistema de ATM desenvolvida no AIR. ZF foi pro vinagre e portado para outra tecnologia - Tanto o AIR quanto a escolha da Zend Framework foram uma falha.

A ZF tinha falhas de arquitetura que mesmo o "dinheiro infinito" de um banco para salvar um projeto não teve solução, a conclusão de outros analistas e pessoas com 20, 30 anos de experiência em projetos de grande porte é que a escolha combinada de duas arquiteturas ruins quebrou toda a vialidade do projeto.