Django

Django

I've been critical of Django in the past for a lack of focus on safety and data integrity, but there is really nothing else that can make a solo founder as productive, so I've bitten the bullet (and been careful with my database configuration and transaction management).

Swapped out the built-in template engine for the Jinja2 backend though--should have done that from the start!

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.

Since 2011 our frontend was in Django monolith. However, in 2016 we decide to separate #Frontend from Django for independent development and created the custom isomorphic app based on Node.js and React. Now we realized that not need all abilities of the server, and it is sufficient to generate a static site. Gatsby is suitable for our purposes. We can generate HTML from markdown and React views very simply. So, we are updating our frontend to Gatsby now, and maybe we will use Netlify for deployment soon. This will speed up the delivery of new features to production.

#StaticSiteGenerators #StaticWebHosting

Python Django PostgreSQL Bootstrap jQuery

Healthchecks.io is a SaaS cron monitoring service. I needed a tool to monitor my cron jobs. I was not happy with the existing options, so I wrote one. The initial goal was to get to a MVP state, and use it myself. The followup goals were to add functionality and polish the user interface, while keeping the UI and the under the hood stuff as simple and clean as possible.

Python and DJango were obvious choices as I was already familiar with them, and knew that many of Django's built-in features would come handy in this project: ORM, testing infrastructure, user authentication, templates, form handling.

On the UI side, instead of doing the trendy "React JS app talking to API endpoints" thing, I went with the traditional HTML forms, and full page reloads. I was aiming for the max simplicity. Paraphrasing Kevin from The Office, why waste time write lot JS when form submit do trick. The frontend does however use some JS, for example, to support live-updating dashboards.

The backend is also aiming for max simplicity, and I've tried to keep the number of components to the minimum. For example, a message broker or a key-value store could be handy, but so far I'm getting away with storing everything in the Postgres database.

The deployment and hosting setup is also rather primitive by today's standards. uWSGI runs the Django app, with a nginx reverse proxy in front. uWSGI and nginx are run as systemd services on bare metal servers. Traffic is proxied through Cloudflare Load Balancer, which allows for relatively easy rolling code upgrades. I use Fabric for automating server maintenance. I did use Ansible for a while but moved back to Fabric: my Ansible playbooks were slower, and I could not get used to mixing YAML and Jinja templating.

Healthchecks.io tech decisions in one word: KISS. Use boring tools that get the job done.

Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.

Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.

For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.

However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.

All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.

Sentry started as (and remains) an open-source project, growing out of an error logging tool built in 2008. That original build nine years ago was Django and Celery (Python’s asynchronous task codebase), with PostgreSQL as the database and Redis as the power behind Celery.

We displayed a truly shrewd notion of branding even then, giving the project a catchy name that companies the world over remain jealous of to this day: django-db-log. For the longest time, Sentry’s subtitle on GitHub was “A simple Django app, built with love.” A slightly more accurate description probably would have included Starcraft and Soylent alongside love; regardless, this captured what Sentry was all about.

#MessageQueue #InMemoryDatabases

Our backend is a large Django app. We use lots of django-rest-framework to interface with the client side. Django