3 ms·
what's not spoken about in the above article ? ease of use. in ruby If I want to use kafka I can use karafka. or redis streams via the redis library. likewise
by dzonga 1y ago
what's not spoken about in the above article ?
ease of use. in ruby If I want to use kafka I can use karafka. or redis streams via the redis library. likewise if kafka is too complex to run there's countless alternatives which work as well - hell even 0mq with client libraries.
now with the postgres version I have to write my own stuff which I might not where it's gonna lead me.
postgres is scalable, no one doubts that. but what people forget to mention is the ecosystem around certain tools.
- j45 1y agoI’m not sure where it says you have to write your own stuff, there seem to be some of queues with libraries. https://github.com/dhamaniasad/awesome-postgres https://github.com/dhamaniasad/awesome-postgres There is at least a Python example here.
- dagss 1y agoWork queues is easy. It is significantly more work for the client side implementation of event log consumers, which the article also talk about. For instance persisting the client side cursors. And I have not seen widely used standard implementations of those. (I started one myself once but didn't finish.)
- enether 1y agoThat's true. There seems to be two planes of ease of use - the app layer (library) and the infra layer (hosting). The app layer for Postgres is still in development, so if you currently want to run pub-sub (Kafka) on it, it will be extra work to develop that abstraction. I hope somebody creates such a library. It's a one-time cost but then will make it easier for everybody.