Flux, a arquitetura JavaScript que funciona
Com o surgimento da web 2.0 e do HTML5, o desenvolvimento web passou a ter cada vez mais lógica sendo executada no navegador, a quantidade de código JavaScript só cresce e vai ficando cada vez maior e mais difícil de manter.
Para tentar resolver este problema, surgiram alguns frameworks baseados em MVC, como o Backbone, Ember e o AngularJS. Estes frameworks ajudaram a evoluir muito a forma que escrevemos nossas aplicações JavaScript.
Problemática
Apesar de tecnologias como o AngularJS melhorarem bastante a divisão de responsabilidades no código javascript, ele apresenta falhas graves de inconsistência de dados, o controller tem excesso de comunicação com a view. E esse mesmo problema se repete no Emberjs.
Talvez você esteja se perguntando como que dois frameworks com códigos completamente diferentes e escritos por pessoas diferentes podem apresentar exatamente o mesmo problema. A resposta é bem simples: O problema não é de implementação ou escrita de código, mas sim padrão de arquitetura utilizado. Ambos frameworks utilizam a arquitetura MVC.
Para entender qual o problema do MVC com o JavaScript precisamos dar uma olhada em seu modelo de Fluxo de dados.
Observe que no modelo MVC existe fluxo de dados unidirecional partindo do controller para a view e voltando da view para o controller. Ou seja, os dados tanto podem vir da view para o controller, quanto do controller para a view.
Este conceito é bastante simples de ser entendido no backend, basta separarmos em dois cenários, GET e POST.
GET
O controller recebe o pedido, consulta na model e entrega para a view
POST
A view envia dos dados em um formulário ou Ajax para o controller, o controller recebe os dados e persiste no banco de dados utilizando a model
Apesar do MVC ser bidirecional, no backend ele em tempo de execução tem um comportamento unidirecional se considerarmos o ciclo de vida dos objetos, como podemos ver no diagrama abaixo.
MVC no Front-End não é tão simples assim
No JavaScript existe uma diferença fundamental no tempo de execução do código que torna o MVC ineficiente como arquitetura Front-End. O tempo de vida dos objetos. Diferente do backend que uma requisição GET é atendida, respondida e logo após isso todos os objetos são destruídos, no JavaScript todos os objetos utilizados na interação GET permanecem vivos e compartilham o mesmo estado com a requisição POST.
Two-way data binding, a solução que virou problema
Para implementar o fluxo de dados bidirecionais os frameworks javascript implementam a solução de two-way data binding que basicamente observa o conjunto de dados de instante em instante verificando se houve alguma alteração no mesmo, quando uma alteração é detectada os novos dados são reescritos na view.
- Baixa Performance
A necessidade de um observador rodando de tempos em tempos verificando se algum dados foi alterado, prejudica bastante a performance da aplicação causando grande lentidão conforme o seu crescimento.
2. Inconsistência de dados
Devido a grande quantidade de observers alterando a view e o modelo a cada instante, e a natureza assíncrona do JavaScript, fica cada vez mais difícil garantir consistência dos dados e o que realmente acontece fica cada vez mais fora do controle do desenvolvedor.
3. Escalabilidade
Escalabilidade tem haver com crescimento, e uma aplicação que fica pior a cada vez que cresce não tem um modelo eficiente de escalabilidade.
Tá… mas e o Flux?
O Flux é a arquitetura de aplicativos que o Facebook utiliza para criar aplicações do lado front-end.
Tendo em mente como funciona MVC no front-end e quais os problemas causados por ele, fica até sugestivo imaginar uma solução para esses problemas. Se os problemas do MVC são causados pelo fluxo bidirecional de dados… Por que não construimos uma arquitetura com fluxo unidirecional!?
É exatamente isso que a arquitetura Flux faz!
Vejamos o diagrama da arquitetura do Flux abaixo.
O Flux é composto por um conjunto de quatro interfaces distintas que comunicam-se de forma unidirecional.
Vamos ver cada uma detalhadamente.
Dispatcher
O dispatcher é responsável por centralizar o registro de callbacks e e emissão de eventos. Ele recebe as ações e as encaminha para a Store.
Cada aplicação deve conter apenas um único dispatcher.
Store
A store é responsável por manter os dados de uma aplicação. O que temos mais próximo disso no angular é o chamado “scope”. A alteração de dados em uma store é feita através de actions recebidas através do dispatcher.
A store também é responsável por emitir um evento “change” cada vez um de seus dados é alterado.
View
A view no Flux tem exatamente a mesma função de exibição de dados que o MVC. Por este motivo a view pode ser qualquer estrutura, assim como em outras arquiteturas. Um componente React, VueJS ou até uma função javascript que gere HTML. Desde que exiba os dados armazedanos na Store e dispare as actions através da interação com o usuário.
Action
A action é de fato a API interna da sua aplicação. Elas discrevem a forma que qualquer coisa interage com a sua aplicação.
Exemplo: AdiconaUsuario, RemoveUsuario.
Como começar com o Flux?
Existem algumas bibliotecas que implementam a arquitetura Flux. A minha favorita é a Vuex com o VueJs. Se você utiliza React, pode começar por Redux ou com a biblioteca Reflux.
Conclusão
Vimos que mesmo um padrão como MVC que é utilizado desde 1979, não é a melhor solução de arquitetura para todos os contextos ou para resolver todos os problema.
Ainda temos muito que aprender e o desenvolvimento front-end ainda não atingiu o mesmo nível de maturidade do backend que já há muito tempo utiliza um design pattern que funciona bem para seu contexto.
Acredito que o Flux seja um forte candidato a ocupar o lugar que hoje o MVC ocupa no desenvolvimento backend. Ainda é muito cedo para afirmar isso e com as diversar implementações da arquitetura Flux, a tendência é que o padrão seja refinado e amadurecido.
É importate deixar claro que eu não acredito que o Flux seja o futuro da arquitetura front-end. Ele é o presente, já funciona muito bem, e o melhor momento para estudar Flux, é agora.
Obrigado por ler este post. Eu gostaria muito de ouvir sua opinião nos comentários abaixo. Se você gostou do post, clique no coração verde abaixo e saberei que você quer ver mais conteúdo como este aqui.
