Redux: Redux dan hubungannya dengan CQRS (dan hal lainnya)

Jadi sumber peristiwa, jika Anda belum pernah menemukannya sebelumnya, memperlakukan semua yang terjadi di domain Anda sebagai "peristiwa", mencatat setiap peristiwa, dan menganggap peristiwa sebagai sumber kebenaran. Semua data lain hanya dilihat sebagai status turunan, dan harus dapat dibuat ulang dengan memutar ulang peristiwa.

Ada analogi yang sangat kuat dengan Redux di sini, saya pikir. Tindakan adalah peristiwa, dan menggunakan fungsi peredam murni untuk mengubah status menjamin bahwa memutar ulang tindakan akan membuat Anda kembali ke status yang sama.

Sumber acara dan CQRS berjalan beriringan, tetapi dimungkinkan untuk melakukan salah satunya tanpa yang lain. (Tidak semua pendukung utama sumber acara akan setuju dengan pernyataan itu, tapi itu diskusi lain.)

Panjang dan pendeknya adalah: Saya pikir ada hal-hal menarik untuk dipelajari dari CQRS dan Sumber Acara, dan mereka dapat membantu mendapatkan kejelasan seputar beberapa ide di Redux.

Saya menemukan bahasa dari CQRS lebih jelas daripada bahasa Flux dan Redux, tapi itu mungkin masalah selera. Saya tentu berpikir kata "Toko" telah menjadi sangat berlebihan di dunia Flux.

PS Saya mungkin, ketika saya mendapatkan waktu, melihat apakah saya dapat mengambil contoh mainan saya dan mengubahnya untuk menggunakan tindakan serial. Seharusnya tidak sulit, dan akan membantu menyingkirkan beberapa sihir hitam metaprogramming di bawah tenda.

+1

Untuk yang tidak terbiasa dengan CQRS + Sumber Acara, inilah sumber yang bagus untuk belajar:
http://cqrs.nu/tutorial/cs/01-design

@notahat , saya setuju dengan Anda:

ada hal menarik yang bisa dipelajari baik dari CQRS maupun Event Sourcing […]
Saya menemukan bahasa dari CQRS lebih jelas daripada bahasa dari Flux dan Redux[…]

IMHO, CQRS, dan Flux sangat mirip, hanya berbeda dalam terminologinya, sedangkan Event-Source persis seperti yang diimplementasikan Redux DevTools.

Saya menambahkan diagram yang mudah-mudahan akan membuat apa yang saya lakukan dengan contoh CQRS mainan saya sedikit lebih jelas: https://github.com/envato/zero-flux/blob/master/docs/zero-flux.pdf

Meskipun mungkin tidak disengaja, "satu toko" di redux mengingatkan saya pada presentasi oleh @gregoryyoung di mana dia menjelaskan " Keadaan Saat Ini adalah Lipatan Kiri dari perilaku sebelumnya "

@gaearon Apakah menurut Anda ada korelasi langsung antara toko Redux dan ide di balik EventStore ?

Saya setuju, dalam pengalaman saya menggunakan beberapa implementasi Flux, actions hanya (peristiwa | sinyal | pesan). Saya pikir nama action adalah pilihan yang buruk karena menyiratkan sesuatu yang lain (melakukan sesuatu).

Biasanya melakukan sesuatu yang berubah-ubah terjadi dalam tindakan asinkron. Itu mungkin lebih baik disebut perintah.

Penutupan, karena ini tampaknya tidak dapat ditindaklanjuti.

Pencipta aksi pada dasarnya adalah perintah
Tindakan pada dasarnya adalah peristiwa
Dispatch() secara efektif adalah bus perintah
Toko kurang lebih adalah proyeksi tampilan

Flux & Redux adalah implementasi IMO dari pola / prinsip CQRS umum.

Dari diskusi sebelumnya yang saya lakukan, saya pikir saya ingat alasan untuk terminologi baru adalah

1. Kesamaan itu diperhatikan kemudian
2. Untuk menghindari menghalangi pengembang dengan bagasi dari implementasi / pengetahuan yang ada

Seperti yang Anda katakan, prinsip CQRS sering digabungkan dengan DDD/Event Sourcing dll - yang menurut saya dapat mengurangi ide inti sederhana.

@glenjamin bagi saya pembuat tindakan tidak boleh diperintah. Kami meninggalkan di frontend jadi pada dasarnya tidak ada perintah, ketika pengguna melakukan beberapa tindakan di UI itu seharusnya menjadi sebuah acara.

Konsep backend tidak selalu dapat secara ketat berhubungan dengan konsep frontend, karena backend menerima maksud pengguna secara aynchronous sementara front menerimanya secara serempak, jadi memang hal-hal selalu terjadi di masa lalu.

Saya rasa pembuat aksi tidak diperlukan sama sekali, terutama jika Anda mulai menggunakan redux-saga. Lihat bagaimana saya mengganti pembuat tindakan di sini: 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 })
        }
      }
    }

Juga hanya menulis sedikit tentang bagaimana Domain-Driven-Design (sering digunakan di backend dengan eventsourcing) juga dapat digunakan di frontend. Lihat https://github.com/rackt/redux/issues/1315#issuecomment -179164091

Hai, saya pikir ini adalah topik yang sangat menarik! Dalam proyek saya, saya telah menggunakan react-redux dan thunks untuk membuat dasar-dasar front-end. Saya telah lama merencanakan untuk menggunakan sumber acara/CQRS di server untuk menangani, memproses, dan mengoptimalkan data. Dalam belajar, dan mencintai, Redux saya menyadari bahwa ini kemungkinan besar akan menjadi lingkungan yang sempurna untuk memproses perintah sisi server dan menghasilkan pos pemeriksaan yang akan dilihat klien. Toko sebagian besar akan seperti cache kompleks untuk penyimpanan data, dimuat sesuai permintaan. Saat perintah masuk, redux-sagas (atau mungkin thunks) akan memprosesnya dan mengirim tindakan baik ke persistensi (pos pemeriksaan) dan reduksi. Klien akan membaca hasil ini setelah menerima pembaruan RT dan me-refresh status redux mereka.

Apakah ada yang punya pengalaman dengan ini, atau ada rekomendasi yang menentangnya?

@tvedtorama Saya setuju dengan Anda, Redux dapat bekerja di backend/server-side bahkan seperti web server atau seluruh backend Anda.
Saya sedang mengerjakan beberapa proyek seperti redux-boot , redux-boot-webserver dan sebagai contoh hades-server yang menunjukkan bagaimana Anda dapat membangun modul backend berdasarkan Redux API.

Hei, jika Anda ingin menggunakan Redux untuk backend, ingat Redux adalah perpustakaan yang sangat kecil hanya 70loc secara konseptual, dan konsep Redux sebagian besar terinspirasi dari sistem pemrosesan aliran backend yang ada.

Alih-alih mem-porting kembali Redux mentah ke backend, di mana sebagian besar perkakas (devtools/react-redux/reselect...) tidak dapat digunakan, dan banyak perkakas yang diperlukan tidak ada (persistensi log, indeksasi status, snapshotting, dan log persisten replay), hanya untuk menggunakan kembali 70loc yang ada ini, mengapa tidak memanfaatkan perkakas backend yang ada yang memecahkan masalah bahkan sebelum Redux ada di tempat pertama?

Saya sedang memikirkan alat yang sangat sederhana, seperti EventStore , yang memungkinkan untuk waktu yang lama untuk

Untuk kasus penggunaan yang lebih canggih, banyak alat juga sudah ada, seperti Kafka, Samza, Storm...

Jangan lupa untuk melihat sebagai desain berbasis domain, karena memodelkan aplikasi Anda dengan peristiwa mungkin tidak cukup dalam banyak kasus, dan Anda mungkin harus memahami apa itu konteks terbatas dan juga akar agregat.

Sekedar menambahkan bahwa sebenarnya devtools dapat digunakan di backend melalui soket, berikut ini sebuah contoh .

hebat @zalmoxisus :)

Tapi tidak yakin itu sangat berguna untuk backend, saya harus menunggu untuk melihat penggunaan sebenarnya untuk diyakinkan :p. Orang-orang yang membuat aplikasi yang bersumber dari peristiwa biasanya memutar ulang seluruh log setelah perubahan peredam/proyeksi, dan menurut pendapat saya, kecil kemungkinan pengguna menggunakan perjalanan waktu. Akhirnya dapat membantu untuk mengatur ulang status yang diberikan untuk mereproduksi konteks bug, tetapi itu sudah disediakan oleh snapshot :)

@slorber Terima kasih atas umpan balik yang bagus! Saya akan melihat ke alat bertarget server yang Anda sebutkan. Namun, saya pikir kemampuan untuk menggunakan kerangka kerja yang sama di front-end dan server bisa menjadi keuntungan tersendiri, karena ini mengurangi kurva belajar dari tumpukan alat. Saya bahkan berharap untuk menggunakan kembali beberapa reduksi di antara lapisan. Masalah DDD pasti juga merupakan masalah yang valid, dan orang harus berhati-hati untuk tidak hanya menyalin struktur ujung depan. Saya berpikir untuk berurusan dengan konteks terbatas baik dengan hanya mendefinisikan struktur paralel di toko - atau toko paralel dengan kisah/pereduksi yang berbeda sama sekali. Struktur paralel ini kemudian sebagian akan merespons peristiwa yang sama, tetapi menghitung statusnya secara berbeda.

@ sebas5384 Proyek yang sangat menarik, saya akan mencoba melihat lebih dalam ketika waktu memungkinkan.

@notahat Terima kasih banyak! Apakah Anda memiliki salinan lain dari diagram yang Anda buat di suatu tempat? Tautan itu tampaknya mati.