1ea2f188ce
Since essentially the first use of Tornado in Zulip, we've been maintaining our Tornado+Django system, AsyncDjangoHandler, with several hundred lines of Django code copied into it. The goal for that code was simple: We wanted a way to use our Django middleware (for code sharing reasons) inside a Tornado process (since we wanted to use Tornado for our async events system). As part of the Django 2.2.x upgrade, I looked at upgrading this implementation to be based off modern Django, and it's definitely possible to do that: * Continue forking load_middleware to save response middleware. * Continue manually running the Django response middleware. * Continue working out a hack involving copying all of _get_response to change a couple lines allowing us our Tornado code to not actually return the Django HttpResponse so we can long-poll. The previous hack of returning None stopped being viable with the Django 2.2 MiddlewareMixin.__call__ implementation. But I decided to take this opportunity to look at trying to avoid copying material Django code, and there is a way to do it: * Replace RespondAsynchronously with a response.asynchronous attribute on the HttpResponse; this allows Django to run its normal plumbing happily in a way that should be stable over time, and then we proceed to discard the response inside the Tornado `get()` method to implement long-polling. (Better yet might be raising an exception?). This lets us eliminate maintaining a patched copy of _get_response. * Removing the @asynchronous decorator, which didn't add anything now that we only have one API endpoint backend (with two frontend call points) that could call into this. Combined with the last bullet, this lets us remove a significant hack from our never_cache_responses function. * Calling the normal Django `get_response` method from zulip_finish after creating a duplicate request to process, rather than writing totally custom code to do that. This lets us eliminate maintaining a patched copy of Django's load_middleware. * Adding detailed comments explaining how this is supposed to work, what problems we encounter, and how we solve various problems, which is critical to being able to modify this code in the future. A key advantage of these changes is that the exact same code should work on Django 1.11, Django 2.2, and Django 3.x, because we're no longer copying large blocks of core Django code and thus should be much less vulnerable to refactors. There may be a modest performance downside, in that we now run both request and response middleware twice when longpolling (once for the request we discard). We may be able to avoid the expensive part of it, Zulip's own request/response middleware, with a bit of additional custom code to save work for requests where we're planning to discard the response. Profiling will be important to understanding what's worth doing here. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| .tx | ||
| analytics | ||
| confirmation | ||
| corporate | ||
| docs | ||
| frontend_tests | ||
| locale | ||
| pgroonga | ||
| puppet | ||
| requirements | ||
| scripts | ||
| static | ||
| stubs | ||
| templates | ||
| tools | ||
| zerver | ||
| zilencer | ||
| zproject | ||
| zthumbor | ||
| .browserslistrc | ||
| .codecov.yml | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlint | ||
| .isort.cfg | ||
| .npmignore | ||
| .stylelintrc | ||
| .travis.yml | ||
| .yarnrc | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile-postgresql | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
| Vagrantfile | ||
| babel.config.js | ||
| manage.py | ||
| mypy.ini | ||
| package.json | ||
| postcss.config.js | ||
| tsconfig.json | ||
| version.py | ||
| yarn.lock | ||
README.md
Zulip overview
Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 500 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project.
Getting started
Click on the appropriate link below. If nothing seems to apply, join us on the Zulip community server and tell us what's up!
You might be interested in:
-
Contributing code. Check out our guide for new contributors to get started. Zulip prides itself on maintaining a clean and well-tested codebase, and a stock of hundreds of beginner-friendly issues.
-
Contributing non-code. Report an issue, translate Zulip into your language, write for the Zulip blog, or give us feedback. We would love to hear from you, even if you're just trying the product out.
-
Supporting Zulip. Advocate for your organization to use Zulip, write a review in the mobile app stores, or upvote Zulip on product comparison sites.
-
Checking Zulip out. The best way to see Zulip in action is to drop by the Zulip community server. We also recommend reading Zulip for open source, Zulip for companies, or Zulip for working groups and part time communities.
-
Running a Zulip server. Use a preconfigured Digital Ocean droplet, install Zulip directly, or use Zulip's experimental Docker image. Commercial support is available; see https://zulipchat.com/plans for details.
-
Using Zulip without setting up a server. https://zulipchat.com offers free and commercial hosting.
-
Applying for a Zulip internship. Zulip runs internship programs with Outreachy, Google Summer of Code, and the MIT Externship program. Zulip also participates in Google Code-In. More information is available here.
You may also be interested in reading our blog or following us on twitter. Zulip is distributed under the Apache 2.0 license.