3 ms·

We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq

We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq and Memcached just to run a chat?

hobbescotch 8y ago
This would certainly make it easier https://github.com/zulip/docker-zulip/blob/master/docker-compose.yml https://github.com/zulip/docker-zulip/blob/master/docker-com...
- Polyisoprene 8y ago
  Well, it’s not fewer components regardless how you package it. Running docker compose wasn’t enough to get into a fully configured system to be able to evaluate it even.
  - seedie 8y ago
    Do you remember the problems you ran into? I'm evaluating zulip with the help of the docker container (1.9.0-rc2) at the moment and docker-compose was enough to get it running.
    - Polyisoprene 8y ago
      Unfortunately not. It was a while ago, so I might have been unlucky with the version I tried. I believe after half a day of struggling to get it working, I got to the point where I was required to setup an organization or something like that and quit at that point and spent some time trying to remove everything.
TheDong 8y ago
> more of a tech demo than a product It is neither a tech demo nor a product, it is a mature open source project. In fact, in my mind tech demos tend towards having fewer mature components. > Redis, Postgres, Rabbitmq and Memcached just to run a chat That set of dependencies seems quite normal to me for a mature project. Mastodon (the most popular open-source-twitterish-thing) has a similar set of dependencies, and is also effectively just chat as you say. Discourse, a popular open source forum, is also basically just chat, and has a similar set of dependencies. In the case of zulip, you can even use a hosted version and avoid running anything yourself. I don't understand why its totally normal set of dependencies turns you off so harshly. I'll happily take a project using redis/postgresql/etc instead of trying to build its own versions of those baked into the binary because components like postgres/redis/etc have great documentation, tooling for metrics and monitoring, etc... If the project bakes its own stuff in itself to avoid taking on dependencies, I doubt it will either be as good or as easy to manage.
- wmf 8y ago
  IMO it would be nice to have scaled-down implementations of caching, queueing, etc. for "small" installations of self-hosted apps to reduce the number and complexity of dependencies. But first there would have to be a market for self-hosting.
mockingbirdy 8y ago
It took us 10 minutes to run a production-ready Zulip server. The installation script handles everything without any issues. https://zulip.readthedocs.io/en/latest/production/install.html https://zulip.readthedocs.io/en/latest/production/install.ht... > just to run a chat Don't overlook the fact that this is a scalable and stable solution used by many companies with thousands of users for each instance. I would have my doubts about the project if it wouldn't use those components.
- Polyisoprene 8y ago
  I certainly believe it’s scalable, but I have a hard time seeing the need for two caching products, a queue and a db just to get it to start.
  - abraae 8y ago
    Do you think robust software should also have a demo packaging, that somehow swaps out all the queuing, caching, database etc. for something else just so that it is super easy to spin up?
    - Polyisoprene 8y ago
      No?
paxy 8y ago
How is a basic database, cache and queue too much?
- mikewhy 8y ago
  It's not, but couldn't Redis do what Memcached and RabbitMQ are doing?
  - menacingly 8y ago
    I could see an argument that Memcached is redundant, but it would definitely make sense to me to throw in a queue with some richer queueyness for a chat app

We looked at it briefly, but the number of components make it look more of a tech demo than a product meant to be installed on-prem. Redis, Postgres, Rabbitmq and Memcached just to run a chat?

hobbescotch 8y ago

This would certainly make it easier https://github.com/zulip/docker-zulip/blob/master/docker-compose.yml https://github.com/zulip/docker-zulip/blob/master/docker-com...

Polyisoprene 8y ago
Well, it’s not fewer components regardless how you package it. Running docker compose wasn’t enough to get into a fully configured system to be able to evaluate it even.
- seedie 8y ago
  Do you remember the problems you ran into? I'm evaluating zulip with the help of the docker container (1.9.0-rc2) at the moment and docker-compose was enough to get it running.
  - Polyisoprene 8y ago
    Unfortunately not. It was a while ago, so I might have been unlucky with the version I tried. I believe after half a day of struggling to get it working, I got to the point where I was required to setup an organization or something like that and quit at that point and spent some time trying to remove everything.

TheDong 8y ago

> more of a tech demo than a product It is neither a tech demo nor a product, it is a mature open source project. In fact, in my mind tech demos tend towards having fewer mature components. > Redis, Postgres, Rabbitmq and Memcached just to run a chat That set of dependencies seems quite normal to me for a mature project. Mastodon (the most popular open-source-twitterish-thing) has a similar set of dependencies, and is also effectively just chat as you say. Discourse, a popular open source forum, is also basically just chat, and has a similar set of dependencies. In the case of zulip, you can even use a hosted version and avoid running anything yourself. I don't understand why its totally normal set of dependencies turns you off so harshly. I'll happily take a project using redis/postgresql/etc instead of trying to build its own versions of those baked into the binary because components like postgres/redis/etc have great documentation, tooling for metrics and monitoring, etc... If the project bakes its own stuff in itself to avoid taking on dependencies, I doubt it will either be as good or as easy to manage.

wmf 8y ago
IMO it would be nice to have scaled-down implementations of caching, queueing, etc. for "small" installations of self-hosted apps to reduce the number and complexity of dependencies. But first there would have to be a market for self-hosting.

mockingbirdy 8y ago

It took us 10 minutes to run a production-ready Zulip server. The installation script handles everything without any issues. https://zulip.readthedocs.io/en/latest/production/install.html https://zulip.readthedocs.io/en/latest/production/install.ht... > just to run a chat Don't overlook the fact that this is a scalable and stable solution used by many companies with thousands of users for each instance. I would have my doubts about the project if it wouldn't use those components.

Polyisoprene 8y ago
I certainly believe it’s scalable, but I have a hard time seeing the need for two caching products, a queue and a db just to get it to start.
- abraae 8y ago
  Do you think robust software should also have a demo packaging, that somehow swaps out all the queuing, caching, database etc. for something else just so that it is super easy to spin up?
  - Polyisoprene 8y ago
    No?

paxy 8y ago

How is a basic database, cache and queue too much?

mikewhy 8y ago
It's not, but couldn't Redis do what Memcached and RabbitMQ are doing?
- menacingly 8y ago
  I could see an argument that Memcached is redundant, but it would definitely make sense to me to throw in a queue with some richer queueyness for a chat app