Node-redis: Peta jalan

Dibuat pada 21 Apr 2016  ·  17Komentar  ·  Sumber: NodeRedis/node-redis

EDIT: @Salakar : Lihat komentar di bawah; https://github.com/NodeRedis/node_redis/issues/1040#issuecomment -581418899


Peta jalan ini tidak diurutkan dan tidak memiliki tanggal tetap tetapi lebih merupakan gabungan umum.

Fitur utama yang akan diimplementasikan

  • [ ] Gugus
  • [ ] Penjaga
  • [ ] Trafo masukan
  • [ ] Trafo keluaran
  • [ ] Dukungan janji asli
  • [ ] Pembatas antrian offline
  • [ ] Dukungan skrip yang lebih baik / tambahkan perintah individual
  • [ ] Lebih baik tetap hidupkan fungsi / tingkatkan deteksi koneksi mati

    Hal-hal lain yang harus ditangani

  • [ ] Dokumentasikan semua kode (JSDoc)

  • [ ] Jadikan API yang tidak terdokumentasi menjadi privat
  • [ ] Perbarui dokumentasi README agar lebih berguna
  • [ ] Perbaiki windows spawn di appveyor
  • [x] Jejak tumpukan yang lebih baik saat tidak dalam mode produksi
  • [ ] Tes asap

Jika Anda merasa ada yang kurang, jangan ragu untuk memberikan saran lebih lanjut / membuka permintaan fitur untuk itu.

meta

Komentar yang paling membantu

Hai semuanya, saya telah mengambil alih sebagai pengelola utama dan memiliki semua akses yang diperlukan sekarang terima kasih banyak kepada @BridgeAR untuk semua pekerjaan yang telah dia lakukan (dan sedang lakukan) di perpustakaan ini dan karena mengizinkan saya mengambil alih.

Saya telah menghabiskan beberapa hari terakhir untuk menyiapkan master untuk rilis, dan beberapa menit yang lalu saya baru saja menerbitkan v3.0.0 ke NPM; https://github.com/NodeRedis/node-redis/releases/tag/v3.0.0 - yang mencakup perubahan ini.

Harapkan rilis reguler - prioritas pertama saya saat ini adalah membuat proyek ini lebih ramah kontributor untuk memastikan bahwa proyek itu hidup dan terus berkembang dan tidak terhalang oleh waktu orang tunggal mana pun. Untuk melakukan ini, saya ingin menumbuhkan set kontributor dangkal yang lebih besar. Dengan ini saya berharap untuk mengurangi masalah sebelumnya dari proyek yang membutuhkan pembaruan tetapi tidak ada orang yang memiliki kekuatan untuk melakukannya. Saya sedang mengerjakan yang berikut ini;

  • [x] Dokumen Kontribusi & Kode Etik
  • [x] Siapkan Kebijakan Kolektif Terbuka dan biaya kontributor

    • Anda akan melihat tombol Sponsor baru yang mengkilap di bagian atas GitHub, saya juga telah maju dan mensponsori sendiri dan melalui perusahaan saya untuk membantu memulainya untuk kontributor masa depan

  • WIP: Rilis otomatisasi & versi semantik (menerbitkan ke NPM, menghasilkan changelog, dll)
  • [x] Tingkatkan CI, misalnya Windows CI sangat lambat & rapuh saat ini

Setelah itu saya akan mengalihkan perhatian saya ke modernisasi (misalnya janji, TypeScript) & kliring utang teknis di basis kode Node Redis. @BridgeAR telah melakukan banyak hal untuk ini, jika Anda penasaran, periksa cabang WIP v4 dan log perubahannya.

Semua 17 komentar

1085 Apakah kami memiliki dukungan untuk dukungan flag NX/XX untuk perintah seperti ZADD

Sudah beberapa bulan, apakah ada timeline yang diperbarui di bagian depan ini?

+1

Adakah kemungkinan dukungan cluster/sharding akan segera hadir? AWS memiliki dukungan cluster redis pada ElastiCache dan saya ingin menggunakannya, tetapi lib ini perlu mengejar set fitur itu agar benar-benar layak :(

Masalah ini harus disematkan IMHO

Juga https://github.com/gosquared/redis-cluster mungkin merupakan solusi yang cukup baik untuk dukungan Cluster?

Pembungkus yang setara untuk penjaga akan sangat bagus. Mungkin https://www.npmjs.com/package/redis-sentinel tetapi sepertinya sudah mati (4 tahun sejak publikasi terakhir).

Mungkin kita harus mendiskusikan masa depan repositori ini di sini; publikasi terakhir ke NPM paket ini lebih dari 2 tahun yang lalu, ada perbaikan pada master yang belum dipublikasikan ke NPM selama hampir 2 tahun, misalnya https://github.com/NodeRedis/node_redis/issues/1331;

Perhatikan bahwa ini bukan saya yang mengeluh tentang @BridgeAR , dia sebenarnya melakukan pekerjaan dengan baik di @nodejs , jadi dapat dimengerti waktunya untuk repo ini terbatas.

Saya bersedia mengambil beberapa beban pemeliharaan tetapi saya ingin beberapa pemikiran tentang tindakan apa yang dapat kami ambil untuk ini mengingat bahwa akses publikasi NPM tidak tersedia untuk repositori yang ada (telah memintanya beberapa kali selama bertahun-tahun) .

Saat ini sepertinya satu-satunya pilihan adalah melakukan fork dan memulai lagi, kecuali jika kita mendapatkan akses.

@Salakar Saya juga bersedia membantu memajukan paket ini. Saya tidak yakin mengapa kita harus mengabaikan nama paket NPM ('redis' sangat kuat). Bukankah @BridgeAR mengontrol paket NPM dan perlu mentransfernya ke seseorang? Ada sedikit tindakan dalam beberapa bulan, dan saya tidak begitu mengerti logika hanya duduk di atasnya, jujur.

Saya tidak berpikir kita harus menghentikan paket ini - ini adalah basis kode yang baik yang dapat diperbarui dan sejumlah besar paket lain bergantung padanya.

Hal lain yang ingin saya kemukakan adalah perubahan RESP3 / Redis 6 yang akan datang yang akan membutuhkan perubahan signifikan. Saya telah melihat fitur ACL di Redis 6 yang seharusnya mudah untuk didukung tetapi kami memerlukan beberapa refactoring serius untuk node_redis. Pekerjaan saya (di Redis Labs) akan mendukung pekerjaan saya pada modul ini, tetapi jika kami tidak dapat melakukan rilis NPM, tidak masuk akal menginvestasikan waktu.

Bukankah @BridgeAR mengontrol paket NPM dan perlu mentransfernya ke seseorang? Ada sedikit tindakan dalam beberapa bulan, dan saya tidak begitu mengerti logika hanya duduk di atasnya, jujur.

Benar, tetapi saya telah meminta akses publikasi NPM sejak Feb 2018, lagi pada Februari 2019, dan permintaan terbaru pada September 2019. Saya sudah mendapat tanggapan tetapi tidak pada topik meminta akses publikasi NPM . https://github.com/NodeRedis/node_redis/issues/1402#issuecomment -490273744 mungkin memberikan beberapa indikasi niat?

Jika transfer tidak akan terjadi maka saya pikir itu perlu dibuat jelas sehingga kami bisa melanjutkan.

ioredis misalnya sangat bagus, dan ada pembicaraan untuk mengkonsolidasikan perpustakaan pada hari itu (saya mengerjakan beberapa alat yang mendasarinya seperti parser baru, denque lib, slot kunci cluster calc dll): https:// github.com/NodeRedis/node_redis#consolidation - its-time-for-celebration - yang menurut saya masih harus menjadi tujuan jangka panjang?

Di luar topik tapi saya mulai bereksperimen membangun klien baru beberapa waktu lalu; https://twitter.com/mikediarmid/status/1074240036936318976 - tapi saya menghentikannya dengan harapan untuk memulai lagi atau membantu mengkonsolidasikan;

Mungkin itu juga rute

image

@Salakar apakah Anda sudah berbicara dengan pemilik NPM lainnya (Matt, Ben, atau Bryce)? Jika Ruben adalah MIA, maka jika kita ingin proyek itu maju, saya tidak berpikir satu orang harus menjadi penghalang jalan. Masalah semacam ini adalah mengapa itu diatur dengan cara ini, saya berasumsi. Saya menemukan komentar pada 1402 mengganggu untuk proyek sumber terbuka, terutama yang tidak terikat (secara organisasi) dengan satu orang.

Saya setuju, ioredis bagus tapi menurut saya ini bukan solusi satu ukuran yang cocok untuk semua. Sejauh konsolidasi, saya pikir parser terpadu adalah tujuan utama yang sudah tercapai. Saya tidak pernah mempertimbangkan bahwa akan ada satu modul sepenuhnya, hanya mengingat perbedaan sintaksis.

@stockholmux : Pekerjaan saya (di Redis Labs) akan mendukung pekerjaan saya pada modul ini, tetapi jika kami tidak dapat melakukan rilis NPM, tidak masuk akal menginvestasikan waktu.

Ditto juga, kami bersedia mendedikasikan sumber daya untuk ini juga @invertase , tetapi jika kami tidak dapat mempublikasikannya maka itu juga tidak masuk akal bagi kami.


@stockholmux : @Salakar apakah Anda sudah berbicara dengan pemilik NPM lainnya (Matt, Ben, atau Bryce)?

Ini adalah poin yang bagus, saya belum melakukannya, saya akan segera menghubungi mereka.


@stockholmux : Saya setuju, ioredis bagus tapi menurut saya ini bukan solusi satu ukuran yang cocok untuk semua. Sejauh konsolidasi, saya pikir parser terpadu adalah tujuan utama yang sudah tercapai. Saya tidak pernah mempertimbangkan bahwa akan ada satu modul sepenuhnya, hanya mengingat perbedaan sintaksis.

Karena minat, apa persyaratan Anda yang dipenuhi lib redis tetapi ioredis tidak? Persyaratan saya melibatkan pengelompokan & penjaga yang saat ini tidak didukung oleh redis kecuali beberapa paket pihak ketiga, beberapa di antaranya juga telah ditinggalkan.

Mungkin protokol koneksi yang mendasari antara dua perpustakaan dapat dibagikan juga, lalu itu murni hanya bagaimana Anda berinteraksi dengan masing-masing yang berbeda?

@Salakar Saya suka pendekatan modular untuk sentinel dan pengelompokan di atas pendekatan monolitik ioredis (sekali lagi, kita perlu berurusan dengan pengabaian). Beberapa orang membutuhkan ini, yang lain tidak. Ekosistem Redis secara keseluruhan semakin besar dan modular adalah cara untuk mendukung lebih banyak tanpa kerumitan, IMHO. Ioredis jauh lebih besar dari basis kode (18.897 vs 7.038 baris kode), yang mungkin lebih banyak fitur, tetapi saya lebih suka tidak memiliki banyak barang tambahan yang tidak saya gunakan.

Tempat di mana saya pikir node_redis memiliki keunggulan besar adalah dukungan modul Redis, yang mudah dengan node_redis dan agak menyusahkan dengan ioredis.

Saya telah menghubungi @mranney melalui DM Twitter dan bertanya apakah dia dapat memberikan saya dan pemilik @stockholmux akses ke GitHub org dan paket NPM, jadi kita akan melihat apa yang terjadi dari itu.

Saya pikir diri saya & @stockholmux setuju bahwa memelihara dan memublikasikan segala sesuatu dari tempat mereka berada saat ini adalah cara terbaik ke depan - jika kita bisa. Jika tidak, saya kira kita dapat mencari alternatif, meskipun saya lebih suka tidak.

Sedikit saran. Mungkin Anda harus mempertimbangkan untuk memigrasi kode sumber ke TypeScript.

Hai semuanya, saya telah mengambil alih sebagai pengelola utama dan memiliki semua akses yang diperlukan sekarang terima kasih banyak kepada @BridgeAR untuk semua pekerjaan yang telah dia lakukan (dan sedang lakukan) di perpustakaan ini dan karena mengizinkan saya mengambil alih.

Saya telah menghabiskan beberapa hari terakhir untuk menyiapkan master untuk rilis, dan beberapa menit yang lalu saya baru saja menerbitkan v3.0.0 ke NPM; https://github.com/NodeRedis/node-redis/releases/tag/v3.0.0 - yang mencakup perubahan ini.

Harapkan rilis reguler - prioritas pertama saya saat ini adalah membuat proyek ini lebih ramah kontributor untuk memastikan bahwa proyek itu hidup dan terus berkembang dan tidak terhalang oleh waktu orang tunggal mana pun. Untuk melakukan ini, saya ingin menumbuhkan set kontributor dangkal yang lebih besar. Dengan ini saya berharap untuk mengurangi masalah sebelumnya dari proyek yang membutuhkan pembaruan tetapi tidak ada orang yang memiliki kekuatan untuk melakukannya. Saya sedang mengerjakan yang berikut ini;

  • [x] Dokumen Kontribusi & Kode Etik
  • [x] Siapkan Kebijakan Kolektif Terbuka dan biaya kontributor

    • Anda akan melihat tombol Sponsor baru yang mengkilap di bagian atas GitHub, saya juga telah maju dan mensponsori sendiri dan melalui perusahaan saya untuk membantu memulainya untuk kontributor masa depan

  • WIP: Rilis otomatisasi & versi semantik (menerbitkan ke NPM, menghasilkan changelog, dll)
  • [x] Tingkatkan CI, misalnya Windows CI sangat lambat & rapuh saat ini

Setelah itu saya akan mengalihkan perhatian saya ke modernisasi (misalnya janji, TypeScript) & kliring utang teknis di basis kode Node Redis. @BridgeAR telah melakukan banyak hal untuk ini, jika Anda penasaran, periksa cabang WIP v4 dan log perubahannya.

@Salakar Selamat! Saya ingin mengambil pekerjaan yang dijanjikan (akan senang membuang async-redis ) tetapi saya menganggap itu sebagian besar sudah selesai sekarang. Kalian punya ide tentang jangka waktu? Apakah Anda menerima kontribusi di bagian depan itu (misalnya: apakah kami memiliki semacam daftar periksa)?

Hai @GCSBOSS , periksa cabang 'v4' - ini adalah refactor yang sedang berlangsung, yang memiliki dukungan janji, tidak ada eta / jangka waktu, maaf

Apakah halaman ini membantu?
0 / 5 - 0 peringkat