Feed powered byStream Blue Logo Copy 5Created with Sketch.
Avatar of Tim Abbott

Tim Abbott

Founder at Zulip

Decision at Zulip about React Native

Avatar of tabbott
Founder at Zulip ·
React NativeReact Native

We've been using React Native for the Zulip mobile apps, and while there's definitely problems with the platform, it's also saved us a huge amount of time.

One of the things that people don't talk about enough is the product thinking cost of maintaining duplicate codebases for the same app, as one would have with a traditional fully native app for both platforms.

That said, the RN ecosystem has frequently been frustrating; RN releases often break important things, often fairly basic features of the underlying implementations (like support for automatically following redirects in various networking contexts) aren't exposed properly, which can result in a bunch of extra work. But at the same time, we're saving all of the work of maintaining two redundant mobile teams, determining and communicating details of the server/client interface with those two teams, and fixing bugs twice.

Overall, we're happy with the React Native decision, since I think it's the best platform available for what it does in 2018. But I'm also interested in whether Flutter, which in our view has a better development strategy/structure, can provide a better cross-platform mobile development experience in the coming years

8 upvotes·16.7K views

Decision at Zulip about GitLab, GitHub

Avatar of tabbott
Founder at Zulip ·
GitLabGitLab
GitHubGitHub

I have mixed feelings on GitHub as a product and our use of it for the Zulip open source project. On the one hand, I do feel that being on GitHub helps people discover Zulip, because we have enough stars (etc.) that we rank highly among projects on the platform. and there is a definite benefit for lowering barriers to contribution (which is important to us) that GitHub has such a dominant position in terms of what everyone has accounts with.

But even ignoring how one might feel about their new corporate owner (MicroSoft), in a lot of ways GitHub is a bad product for open source projects. Years after the "Dear GitHub" letter, there are still basic gaps in its issue tracker: * You can't give someone permission to label/categorize issues without full write access to a project (including ability to merge things to master, post releases, etc.). * You can't let anyone with a GitHub account self-assign issues to themselves. * Many more similar issues.

It's embarrassing, because I've talked to GitHub product managers at various open source events about these things for 3 years, and they always agree the thing is important, but then nothing ever improves in the Issues product. Maybe the new management at MicroSoft will fix their product management situation, but if not, I imagine we'll eventually do the migration to GitLab.

We have a custom bot project, http://github.com/zulip/zulipbot, to deal with some of these issues where possible, and every other large project we talk to does the same thing, more or less.

8 upvotes·12K views

Decision at Zulip about Markdown

Avatar of tabbott
Founder at Zulip ·
MarkdownMarkdown

We've been incredibly happy with the choice of Markdown as the composition language for Zulip:

  • Everyone can write it, since it's just like email and many other products use it.
  • It has a WYSIWYG type experience, so we don't feel the need to integrate a fancy editor like Quill.
  • There are mature markdown processors for every programming language. Having compatible, high-quality implementations for Python and JavaScript is important for doing local echo properly (see our linked Markdown documentation for details of why is necessary).
  • Rendering to HTML is fast, easy to do automated tests for, and easy to debug.

We have had to customize our Markdown implementation somewhat for the chat context, because we don't have the guarantee that content is not split across multiple messages (a good example is that you don't want the "automatically change numbered lists to start at 1" feature in default markdown; you want to restrict that to numbered lists where all the numbers are 1, for example) .

8 upvotes·1.3K views

Decision at Zulip about Redis, Python, RabbitMQ

Avatar of tabbott
Founder at Zulip ·
RedisRedis
PythonPython
RabbitMQRabbitMQ

We've been using RabbitMQ as Zulip's queuing system since we needed a queuing system. What I like about it is that it scales really well and has good libraries for a wide range of platforms, including our own Python. So aside from getting it running, we've had to put basically 0 effort into making it scale for our needs.

However, there's several things that could be better about it: * It's error messages are absolutely terrible; if ever one of our users ends up getting an error with RabbitMQ (even for simple things like a misconfigured hostname), they always end up needing to get help from the Zulip team, because the errors logs are just inscrutable. As an open source project, we've handled this issue by really carefully scripting the installation to be a failure-proof configuration (in this case, setting the RabbitMQ hostname to 127.0.0.1, so that no user-controlled configuration can break it). But it was a real pain to get there and the process of determining we needed to do that caused a significant amount of pain to folks installing Zulip. * The pika library for Python takes a lot of time to startup a RabbitMQ connection; this means that Zulip server restarts are more disruptive than would be ideal. * It's annoying that you need to run the rabbitmqctl management commands as root.

But overall, I like that it has clean, clear semanstics and high scalability, and haven't been tempted to do the work to migrate to something like Redis (which has its own downsides).

4 upvotes·1.2K views

Decision at Zulip about Kubernetes, Docker

Avatar of tabbott
Founder at Zulip ·
KubernetesKubernetes
DockerDocker

We recently adopted the (previously community-developed) Docker image for Zulip, and I've gotten a bunch of experience as part of this process. We didn't have a lot of choice as to whether to use Docker -- as an open source web application, installation options are driven by what users are asking for, and in the container world, that's a Docker image.

To be honest, maintaining a Docker image is kind of a pain, even for something like Zulip where our Debian/Ubuntu install process is super clean and reliable. Docker requires you to run your application's installer in a totally crippled environment (E.g. no unicode locales are installed, so using pip to build Python packages doesn't work until you fix that) to generate a working Dockerfile. But the real pain is the fact that Docker users expect to configure everything via environment variables in e.g. a docker-compose.yml or similar Kubernetes configuration file.

And that results in just about every Docker image for a reusable web application having a giant docker-entrypoint.sh script of semi-duplicated code (ours is currently ~600LOC; those for other popular projects can easily be 2-3X that size) that does a bunch of stuff, including pass what is structurally an array through a shell environment variable and back into our Python-format settings file, which is just a mess.

Since that shell script can have bugs, this is a big maintenance (e.g. right now probably a third of user reports of issues installing a new Zulip server are Docker-specific issues, even though Docker installations are a small fraction of total installations).

Further, a lot of third-party images (e.g. for postgres or redis or RabbitMQ) end up having issues where they have an environment variable for configuring something (E.g. a postgres password), but if you change that variable after the postgres image is first booted, nothing happens, which can be confusing for users (who often assume they can just boot their image with whatever password and clean up the security stuff later).

So, while the Docker/containers ecosystem has a lot of promise, I also feel it has a long way to go before providing a Docker image isn't a significant burden on projects, even ones like us that already have a battle-tested installation process.

3 upvotes·1.4K views

Decision at Zulip about Elasticsearch, MySQL, PostgreSQL

Avatar of tabbott
Founder at Zulip ·
ElasticsearchElasticsearch
MySQLMySQL
PostgreSQLPostgreSQL

We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

I can't recommend it highly enough.

3 upvotes·1K views

Decision at Zulip about Apache HTTP Server, nginx

Avatar of tabbott
Founder at Zulip ·
Apache HTTP ServerApache HTTP Server
nginxnginx

We've been happy with nginx as part of our stack. As an open source web application that folks install on-premise, the configuration system for the webserver is pretty important to us. I have a few complaints (e.g. the configuration syntax for conditionals is a pain), but overall we've found it pretty easy to build a configurable set of options (see link) for how to run Zulip on nginx, both directly and with a remote reverse proxy in front of it, with a minimum of code duplication.

Certainly I've been a lot happier with it than I was working with Apache HTTP Server in past projects.

3 upvotes·878 views

Decision at Zulip about Mercurial, Git

Avatar of tabbott
Founder at Zulip ·
MercurialMercurial
GitGit

I've been excited about Git ever since it got a built-in UI. It's the perfect combination of a really solid, simple data model, which allows an experienced user to predict precisely what a Git subcommand will do, often without needing to read the documentation (see the slides linked from the attached article for details). Most important to me as the lead developer of a large open source project (Zulip) is that it makes it possible to build a really clean, clear development history that I regularly use to understand details of our code history that are critical to making correct changes.

And it performs really, really well. In 2014, I managed Dropbox's migration from Mercurial to Git. And just switching tools made just about every common operation (git status, git log, git commit etc.) 2-10x faster than with Mercurial. It makes sense if you think about it, since Git was designed to perform well with Linux, one of the largest open source projects out there, but it was still a huge productivity increase that we got basically for free.

If you're learning Git, I highly recommend reading the other sections of Zulip's Git Guide; we get a lot of positive feedback from developers on it being a useful resource even for their projects unrelated to Zulip.

3 upvotes·858 views

Decision at Zulip about Markdown, Dropbox, Ghost

Avatar of tabbott
Founder at Zulip ·
MarkdownMarkdown
DropboxDropbox
GhostGhost

We've been using Ghost as the blog software for Zulip since we first needed a blog. I've been pretty happy with using open source software developed by a non-profit, and their editing experience is great. We use Dropbox Paper to draft posts with a nice commenting experience, and then export the Markdown into Ghost when we're ready to publish.

There's a few that could be better, though. My main complaint is they have a 200 character limit for author biographies, which seems arbitrary and unhelpful.

3 upvotes·746 views

Decision at Zulip about Django REST framework, Django

Avatar of tabbott
Founder at Zulip ·
Django REST frameworkDjango REST framework
DjangoDjango

Zulip has been powered by Django since the very early days of its development with Django 1.4, back in 2012. As a reasonably mature web application with significant scale, we're at the stage in many companies' development where one starts to rip out more and more of the web framework to optimize things or just make them work the way we want. (E.g. while I was at Dropbox in early 2016, we discovered we only had about 600 lines of code left from the original Pylons framework that actually ran).

One of the things that has been really fantastic about Django is that we're still happily using it for the vast majority of code in the project, and every time Django comes out with a new release, I read the changelog and get excited about several improvements that actually make my life better. While Django has made some design decisions that I don't agree with (e.g. I'm not a fan of Django REST framework, and think it makes life more difficult), Django also makes it easy to do your own thing, which we've done to great effect (see the linked article for details on our has_request_variables framework).

Overall I think we've gotten a ton of value out of Python and Django and would recommend it to anyone starting a new full-featured web application project today.

3 upvotes·730 views