search

frontendbr / forum

:beer: Portando discussões feitas em grupos (Facebook, Google Groups, Slack, Disqus) para o GitHub Discussions
MIT License
4.25k stars 234 forks source link

Para iniciar um projeto novo, ReactJS + Redux + Saga + Materialize UI, são opções boas e que estão estáveis no mercado? #1532

Closed wilsonneto-dev closed 4 years ago

wilsonneto-dev commented 5 years ago

Galera, iniciando um projeto profissional, na empresa em que estou, estamos migrando de aplicações simples acopladas ao backend e feitas com CSS, HTML e JS simples para ReactJS e APIs Rest.

Para iniciar um projeto novo, ReactJS + Redux + Saga + Materialize UI, são opções boas e que estão estáveis no mercado?

Ouvi algumas pessoas que desencorajam o uso do redux e me indicaram usar context api, também algumas pessoas indicaram usar GraphQL em vez de Rest, já que vou escrever tudo do zero... Qual a opinião de vocês?

Muito obrigado, forte abraço!

glauberm commented 5 years ago

Se são opções boas vai sempre depender da aplicação, né. Mas com certeza são consolidadas no mercado.

Em relação ao Redux vale a pena dar uma lida nesse texto, mas eu diria que se seu app não é muito grande ou tem a pretensão de se tornar muito grande, a complexidade adicionada pelo Redux não vale a pena, e compensa mais investir em composição de componentes e na Context API.

Se vocês vão fazer tudo do zero (back e front-end) eu diria que vale a pena investir em GraphQL, sim. Mas você só citou ferramentas de front; se vocês vão fazer só o front do zero e não pretendem mexer muito no back-end, não recomendaria, não...

kivervinicius commented 5 years ago

Opa, eu aconselho iniciar o projeto sem pensar em redux, context ou algo do tipo, tente pensar em componentes, quando você precisar (você vai sentir que precisa) compartilhar algo em uma cadeia de componentes dai vc testa e ve o que mais lhe agrada, pra ser sincero até hoje não usei sagas em produção, mas uso muito redux. Pensar pequeno acredito que seja a chave. Pra ser sincero, vc vai usar essa api de forma pública? Pretende ter inúmeros desenvolvedores trabalhando para uma mesma api, diversos front-ends (applicativos nativos, pwa, site) consumindo esta ai? caso for não para quase todas vai de rest mesmo, a quantidade de documentação necessária que vc vai ter que ler e a complexidade de todas essas tecnologias não valem a pena o custo beneficio do GraphQL

wilsonneto-dev commented 5 years ago

@glauberm valeu muito pelas dicas, o texto realmente abriu um pouco minha mente para o fato de talvez não precisarmos de redux... Não citei muito sobre backend porque este já está decidido rs .Net Core, e sim vamos levantar ele do zero também.

wilsonneto-dev commented 5 years ago

@kivervinicius muito obrigado! Na verdade muita gente vai consumir esta api, mas todos clientes da mesma aplicação, o back e o front apesar de serem desacoplados, será apenas esta aplicação front e uma aplicação mobile nossa que acessaram a API.

Muito obrigado pelas dicas, valeu!!

eliseumds commented 5 years ago

Eu trabalho num projeto bem grande com JS, TS, Webpack e todas essas goodies de hoje em dia. Dois anos atrás eu tava pirado em redux-saga, comprei livros, fiz apresentações e escrevi muito código. Em retrospectiva, a real é que eu não precisávamos de uma solução tão robusta no front-end. Sim, fica mais fácil de entender fluxos complexos, mas só depois que sua mente absorve todos os novos conceitos que sagas apresentam, e isso leva tempo e custa muito dinheiro. Aqui vão minhas recomendações:

Você precisa de server-side rendering?

Se sim, prepare-se. Isso vai consumir muito recurso e coisas vão explodir por causa das inconsistências entre server e client. Variáveis globais estão fora de questão (use React context), cookies, i18n, variáveis de ambiente, Webpack e etc vão ficar muito mais difíceis. Se as páginas não forem muito dinâmicas, dá pra explorar opções híbridas ou pre-rendering.

Redux

Eu confesso que usei Redux mais do que deveria. Hoje em dia, por exemplo, eu não usaria biblioteca de formulários em Redux por causa de problemas com performance (qualquer ação nos campos gera re-renders no resto da página inteira).

Há certas coisas que são globais mesmo como user, mas dá pra jogar em Context, assim como notificações, modals, API client e etc. Com React hooks fica fácil consumir esses valores de contexto.

Theming

As páginas são complicadas e renderizam muitos componentes? Se sim, CSS-in-JS como Emotion e styled-components podem deixá-las lentas. Nós decidimos manter o bom e velho CSS modules no projeto principal e usamos Emotion em apps menores.

Sagas

A não ser que você tenha business rules realmente complexas no client, evite redux-saga. O componente mais absurdo que criamos foi um uploader com progress, cancellation, previews, cropping e tudo mais, e acabamos implementando mais coisas do que precisávamos justamente porque foram fáceis de modelar com sagas. Mas se contratarmos uma pessoa nova, ela provavelmente não vai entender o que tá rolando pq vai precisar ter fundamentos bem fortes sobre concurrency.

Hoje em dia usamos sagas num servidor de analytics e num outro servidor que gerencia filas de moderação de conteúdo, os dois em tempo real com WebSockets. Na minha opinião, foi uma boa ideia. Com .NET é uma coisa linda também: usando NServiceBus você consegue até persistir o estado das sagas no banco de dados.

Se quiser aprender mais sobre sagas, recomendo começar com o livro Enterprise Integration Patterns, especificamente o capítulo Process Manager.

GraphQL

Não tenho muita experiência com GraphQL. Pelo que vi e usei, funciona bem pra aplicações pequenas e que não precisam de muitos joins. Quando a coisa começa a crescer, aí o bicho pega, principalmente na parte de modelação. No final, parece melhorar e muito a nossa vida como desenvolvedores. Se você decidir usar GraphQL, compartilha depois com a gente a sua experiência. Tem muita coisa pra ler aqui: https://github.com/chentsulin/awesome-graphql.

danilosilvadev commented 5 years ago

@wilsonneto-dev GraphQL eu cheguei a conclusão que funciona mais para empresas grandes com equipes focadas e processos bem definidos tipo o facebook ou se você faz tudo sozinho e sempre será o responsável pelo código. Se não, digo REST te dá flexibilidade para mudar completamente o front sem ter que se matar no back.

ViniciusGularte commented 5 years ago

Aqui na empresa usamos um modelo REST, com Bootstrap e um template próprio, é um SaaS bem grande, no começo quis usar Redux + Saga mais tudo de novo no hype hehe, não deu certo e tirei fora por adicionar complexidade desnecessária, mas como o pessoal falou ae encima, na hora certa, você vai sentir que pode precisar usar, no caso agora estou usando o context api mesmo pra algumas coisas simples no projeto, quando você já tem toda arvore de componentes fica mais identificar os gargalos.

wilsonneto-dev commented 5 years ago

Opa, muito obrigado @ViniciusGularte , @danilosilvadev e @eliseumds , me ajudaram a mudar um pouco a visão em vários fatores que vão ajudar muito na escalabilidade da minha aplicação. Valeu mesmo!!

alexsandro-xpt commented 4 years ago

@eliseumds Voce tem algum projeto demo com o NServiceBus ? Ele é pagou ou free?

eliseumds commented 4 years ago

@alexsandro-xpt infelizmente não tenho. Trabalhei num projeto há uns anos atrás onde a galera curtia muito .NET e falava sobre NServiceBus. Onde estou hoje, usamos Symfony, que é uma delícia, mas não tem algo tão sólido e integrado como NServiceBus que tem logging, monitoring, debugging, DevOps, message broker, tudo no mesmo pacote.

Lembrando que essas ferramentas são complexas e leva-se tempo pra absorver os princípios de DDD (Domain Driven Design) e CQRS.

Ele é pago por node, ou seja, por virtual ou physical machine onde estiver rodando (e não por container). Então se o seu Kubernetes cluster, por ex, tiver 5 nodes e 120 containers, você paga pelos 5 nodes.

alexsandro-xpt commented 4 years ago

@eliseumds então é uma solução paga, eu gostaria de testar para me familiarizar com Sagas.

eliseumds commented 4 years ago

@alexsandro-xpt primeiro, eu gostaria de ressaltar que o conceito de sagas em redux-saga é diferente do usado no mundo back-end. Redux sagas estão mais para Process Managers, uns daemons que ficam rodando em background que, ao capturarem eventos, disparam outros eventos ou side effects (uma notificação no browser, um redirect, etc). No seu sistema operacional há vários daemons rodando, como crond pra executar scheduled jobs e inetd que lida com network requests.

Já no mundo de sistemas distribuídos (microservices), sagas são controllers que lidam com transações distribuídas, que disparam mensagens pra diferentes serviços, e, dependendo do resultado combinados delas, acaba gerando uma mensagem final (o commit). Por ex, uma agência de turismo que te vende um pacote só pode confirmar seu booking depois de que as suas passagens de avião (às vezes envolve múltiplas companhias), seu hotel e seu carro estiverem garantidos. Por isso sempre leva um tempinho pra receber aquele e-mail de confirmação.

Essas ações podem retornar resultados inesperados como:

Quando isso acontece, é papel da saga disparar ações compensatórias. Se você disparou todas as requests em paralelo no início e só uma falhou, você vai ter que gerar requests de cancelamento pra todos os outros serviços, e, provavelmente, enviar uma e-mail pro usuário explicando o que rolou e oferecer alternativas.

Normalmente o framework vai fazer os retries automaticamente no caso de uma falha de comunicação, então isso fica transparente pro desenvolvedor.

Se todas as ações tiverem êxito, a saga vai disparar um evento tipo BookingWasConfirmed. Lá no microservice que lida com bookings, um event handler vai receber essa mensagem e gravar um valor no banco de dados. Ele também pode enviar uma mensagem de notificação pro usuário (e-mail, SMS, whatever).

Uma saga não vai escrever/alterar/deletar/ler nada de um banco de dados. Ela vai trabalhar com os valores/payloads contidos nos eventos que são disparados pelos microservices.

Concluindo, sagas são uma forma de gerenciar transações de longa duração (assíncronas), que dependem de resultados de serviços diferentes.

Algumas sugestões de leitura:

Esse vídeo mostra algumas das coisas da qual eu falei sendo usadas com .NET: https://www.youtube.com/watch?v=KI223ULIFoA.

Rola usar redux-saga no back-end também, como fazemos onde eu trabalho, mas não é uma solução tão robusta porque não seria fácil salvar o estado da transação num banco de dados em casa de falha no sistema.

A galera procura por sagas em sistemas distribuídos normalmente quando já estão gigantes e com serviços bem definidos, o que já é difícil o suficiente pra fazer.

alexsandro-xpt commented 4 years ago

Pois é @eliseumds eu estou procurando uma lib não paga em .net pra ajudar neste processo.