Redux: Redux e sua relação com CQRS (e outras coisas)

Portanto, o sourcing de eventos, se você ainda não encontrou isso, trata tudo o que acontece em seu domínio como um "evento", registra todos os eventos e considera os eventos como a fonte da verdade. Todos os outros dados são apenas vistos como estado derivado e devem poder ser regenerados por eventos de repetição.

Há uma analogia muito forte com Redux aqui, eu acho. Ações são eventos, e o uso de funções puras de redutor para alterar o estado garante que a repetição das ações o trará de volta ao mesmo estado.

O sourcing de eventos e o CQRS andam de mãos dadas, mas é possível fazer um sem o outro. (Nem todos os principais proponentes da fonte de eventos concordariam com essa afirmação, mas isso é outra discussão.)

Resumindo, acho que há coisas interessantes a serem aprendidas tanto com o CQRS quanto com o Event Sourcing, e elas podem ajudar a esclarecer algumas das ideias no Redux.

Eu acho a linguagem do CQRS mais clara do que a do Flux e Redux, mas isso provavelmente é uma questão de gosto. Eu certamente acho que a palavra "Store" ficou muito sobrecarregada no mundo do Flux.

PS: Posso, quando tiver um momento, ver se posso pegar meu exemplo de brinquedo e convertê-lo para usar ações serializáveis. Não deve ser difícil e ajudará a livrar-se de parte da magia negra da metaprogramação por baixo do capô.

+1

Para quem não está familiarizado com CQRS + Event-Source, aqui está um ótimo recurso de aprendizagem:
http://cqrs.nu/tutorial/cs/01-design

@notahat , concordo com você:

há coisas interessantes a serem aprendidas tanto do CQRS quanto do Event Sourcing [...]
Eu acho a linguagem do CQRS mais clara do que a do Flux e Redux [...]

IMHO, CQRS e Flux são muito parecidos, divergindo apenas em sua terminologia, enquanto Event-Source é exatamente o que Redux DevTools implementa.

Eu adicionei um diagrama que espero tornar o que eu estava fazendo com meu exemplo de brinquedo CQRS um pouco mais claro: https://github.com/envato/zero-flux/blob/master/docs/zero-flux.pdf

Embora talvez não seja intencional, a "loja única" em redux me lembra uma apresentação de @gregoryyoung onde ele descreve " O estado atual é uma dobra esquerda de comportamentos anteriores "

@gaearon Você acha que existe uma correlação direta entre a loja Redux e as ideias por trás da EventStore ?

Eu concordo, em minha experiência usando várias implementações de Flux, actions são apenas (eventos | sinais | mensagens). Eu acho que o nome action é uma escolha ruim, pois implica em outra coisa (fazer algo).

Normalmente, fazer algo em fluxo ocorre em uma ação assíncrona. Provavelmente, esses seriam mais bem chamados de comandos.

Fechando, pois isso não parece acionável.

Os criadores de ação são basicamente comandos
Ações são basicamente eventos
Dispatch () é efetivamente um barramento de comando
As lojas são mais ou menos projeções de visualização

Flux e Redux são implementações IMO do padrão / princípio geral CQRS.

Pelas discussões anteriores que tive, acho que me lembro que a razão para uma nova terminologia é

1. A semelhança foi notada mais tarde
2. Para evitar dissuadir os desenvolvedores com a bagagem das implementações / conhecimentos existentes

Como você disse, o princípio CQRS costuma ser confundido com DDD / Event Sourcing etc. - o que eu acho que pode prejudicar a ideia básica simples.

@glenjamin para mim, os criadores de ação não devem ser o comando. Deixamos no frontend, portanto, basicamente, não há comando, quando o usuário executa alguma ação na interface do usuário, deve ser um evento.

Os conceitos de back-end nem sempre estão estritamente relacionados aos conceitos de front-end, porque o back-end recebe a intenção do usuário de maneira assíncrona, enquanto o front a recebe de forma síncrona, então, de fato, as coisas sempre acontecem no passado.

Não acho que os criadores de ação sejam necessários, principalmente se você começar a usar a saga redux. Veja como eu substituo um criador de ação aqui: http://stackoverflow.com/a/34623840/82609

redux-thunk:

    <div onClick={e => dispatch(actions.loadUserProfile(123)}>Robert</div>

    function loadUserProfile(userId) {
      return dispatch => fetch(`http://data.com/${userId}`)
        .then(res => res.json())
        .then(
          data => dispatch({ type: 'USER_PROFILE_LOADED', data }),
          err => dispatch({ type: 'USER_PROFILE_LOAD_FAILED', err })
        );
    }

redux-saga:

    <div onClick={e => dispatch({ type: 'USER_NAME_CLICKED', 123 })}>Robert</div>

    function* loadUserProfileSaga() {
      while(true) {
        const action = yield take("USER_NAME_CLICKED")
        const userId = action.payload;
        try {
          const userProfile = yield fetch('http://data.com/${userId}')
          yield put({ type: 'USER_PROFILE_LOADED', userProfile })
        } 
        catch(err) {
          yield put({ type: 'USER_PROFILE_LOAD_FAILED', err })
        }
      }
    }

Também escrevi um pouco sobre como Domain-Driven-Design (freqüentemente usado em back-end com eventsourcing) também pode ser usado em front-end. Veja https://github.com/rackt/redux/issues/1315#issuecomment -179164091

Olá, acho que este é um tópico muito interessante! Em meu projeto, usei react-redux e thunks para criar o básico do front-end. Há muito tempo planejo usar fonte de eventos / CQRS no servidor para manipular, processar e otimizar dados. Ao aprender, e amar, Redux percebi que este provavelmente será o ambiente perfeito para processar os comandos do lado do servidor e gerar os checkpoints que os clientes verão. O armazenamento será principalmente como um cache complexo para o armazenamento de dados, carregado sob demanda. Conforme os comandos chegam, redux-sagas (ou talvez thunks) irá processá-los e enviar ações para persistência (pontos de verificação) e redutores. Os clientes irão ler o resultado após receber atualizações RT e atualizar seu estado de redux de forma correspondente.

Alguém tem alguma experiência com isso, ou alguma recomendação contra isso?

@tvedtorama Eu concordo com você, Redux pode funcionar no backend / server-side até como um servidor web ou todo o seu backend.
Estou trabalhando em alguns projetos como redux-boot , redux-boot-webserver e como um exemplo de servidor hades que demonstra como você pode construir módulos de backend baseados na API Redux.

Ei, se você quiser usar Redux para o back-end, lembre-se de que Redux é uma biblioteca muito pequena de apenas 70 locais conceitualmente, e os conceitos do Redux são amplamente inspirados em sistemas de processamento de back-end existentes.

Em vez de portar de volta o Redux bruto para o backend, onde a maioria das ferramentas (devtools / react-redux / reselect ...) não pode ser usado, e muitas ferramentas necessárias estão faltando (persistência de log, indexação de estado, instantâneo e log persistente replay), apenas para reutilizar esses 70loc existentes, por que não aproveitar as ferramentas de back-end existentes que resolveram o problema antes mesmo de o Redux existir?

Estou pensando em ferramentas muito simples, como EventStore , que permitem por muito tempo persistir um log de eventos distribuído e construir projeções de log (equivalente aos redutores de ação Redux). Como a projeção pode emitir novos eventos, também pode atuar como uma saga.

Para casos de uso mais avançados, muitas ferramentas já existem também, como Kafka, Samza, Storm ...

Não se esqueça de olhar como um design orientado por domínio, pois modelar seu aplicativo com eventos pode não ser suficiente na maioria dos casos, e você provavelmente deve entender o que é um contexto limitado e também uma raiz agregada.

Apenas para acrescentar que, na verdade, os devtools podem ser usados ​​no backend via sockets, aqui está um exemplo .

ótimo @zalmoxisus :)

Mas não tenho certeza se é muito útil para backend, terei que esperar para ver um uso real disso para me convencer: p. Pessoas que criam aplicativos originados de eventos geralmente reproduzem todo o log após uma mudança de redutor / projeção, e é menos provável que o usuário use a viagem no tempo, na minha opinião. Eventualmente, poderia ajudar a redefinir determinado estado para reproduzir o contexto de um bug, mas já é o que os instantâneos fornecem de qualquer maneira :)

@slorber Obrigado pelo ótimo feedback! Vou dar uma olhada nas ferramentas direcionadas ao servidor que você mencionou. No entanto, acho que a capacidade de usar as mesmas estruturas no front-end e no servidor pode ser uma vantagem em si, pois isso diminui a curva de aprendizado da pilha de ferramentas. Espero até reutilizar alguns dos redutores entre as camadas. Questões de DDD definitivamente também são preocupações válidas, e deve-se ter cuidado para não apenas copiar as estruturas do front end. Eu estava pensando em lidar com contextos limitados simplesmente definindo estruturas paralelas na loja - ou lojas paralelas com diferentes sagas / redutores ao mesmo tempo. Essas estruturas paralelas responderiam parcialmente aos mesmos eventos, mas calculariam seu estado de maneira diferente.

@ sebas5384 Projetos muito interessantes, tentarei

@notahat Muito obrigado! Você tem outra cópia desse diagrama que criou em algum lugar? Esse link parece estar morto.