Decision at Sentry about Redis, PostgreSQL, Celery, Django, InMemoryDatabases, MessageQueue

Avatar of jtcunning
Operations Engineer at Sentry ·
RedisRedisPostgreSQLPostgreSQLCeleryCeleryDjangoDjango
#InMemoryDatabases
#MessageQueue

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

22 upvotes·55.7K views

Decision at Uploadcare about PostCSS, Preact, Ember.js, React, Python, Django

Avatar of dmitry-mukhin

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.

21 upvotes·51K views

Decision at Peergrade about Amazon RDS, Graphene, GraphQL, Django, PostgreSQL

Avatar of malthejorgensen
CTO at Peergrade ·

We recently switched from MongoDB and the Python library MongoEngine to PostgreSQL and Django in order to:

  • Better leverage GraphQL (using the Graphene library)
  • Allow us to use the autogenerated Django admin interface
  • Allow better performance due to the way some of our pages present data
  • Give us more a mature stack in the form of Django replacing MongoEngine, which we had some issues with in the past.

MongoDB was hosted on mlab, and we now host Postgres on Amazon RDS .

13 upvotes·13.9K views

Decision about Python, Django, JavaScript, Node.js

Avatar of foodplanet

Django or NodeJS? Hi, I’m thinking about which software I should use for my web-app. What about Node.js or Django for the back-end? I want to create an online preparation course for the final school exams in my country. At the beginning for maths. The course should contain tutorials and a lot of exercises of different types. E.g. multiple choice, user text/number input and drawing tasks. The exercises should change (different levels) with the learning progress. Wrong questions should asked again with different numbers. I also want a score system and statistics. So far, I have got only limited web development skills. (some HTML, CSS, Bootstrap and Wordpress). I don’t know JavaScript or Python.

Possible pros for Python / Django: - easy syntax, easier to learn for me as a beginner - fast development, earlier release - libraries for mathematical and scientific computation

Possible pros for JavaScript / Node.js: - great performance, better choice for real time applications: user should get the answer for a question quickly

Which software would you use in my case? Are my arguments for Python/NodeJS right? Which kind of database would you use?

Thank you for your answer!

Node.js JavaScript Django Python

11 upvotes·1 comment·10.8K views

Decision at SIA Monkey See Monkey Do about jQuery, Bootstrap, PostgreSQL, Django, Python

Avatar of cuu508

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.

9 upvotes·1 comment·21.5K views

Decision about Django, Redis

Avatar of supermanzer

I use Redis because, based on the case studies I have reviewed, it appears to be the most performant cache database for my Django projects. The ease of configuration and deployment is also a big plus.

Using both higher level view caching as well as low-level QuerySet caching with Redis has allowed me to improve HTTP request times by an order of magnitude.

8 upvotes·8.1K views

Decision at Uploadcare about Netlify, Gatsby, React, Node.js, Django, StaticWebHosting, StaticSiteGenerators, Frontend

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
NetlifyNetlifyGatsbyGatsbyReactReactNode.jsNode.jsDjangoDjango
#StaticWebHosting
#StaticSiteGenerators
#Frontend

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

7 upvotes·29.8K views

Decision at The Paperless Project about Django, Tesseract OCR, Python

Avatar of danielquinn
Senior Developer at Founders4Schools ·

I use Python because it's a beautiful (both visually and in terms of function) and multi-purpose language. In Paperless, Python is the primary connecting tissue holding all of the parts together: it's the basis of the consumption engine (communicating with Tesseract OCR via pyOCR) and the user-interface (based on Django).

7 upvotes·2.8K views

Decision about uWSGI, PostgreSQL, Heroku, Django, Python, GitHub

Avatar of skruger

I find I really like using GitHub because its issue tracker integrates really well into my project flow and the projects feature allows me to organize different efforts into boards. The automation features allow my issues to automatically progress through some states on the boards when I merge pull requests.

My Python / Django app is deployed on Heroku with PostgreSQL database and uWSGI webserver.

5 upvotes·7K views

Decision at Zulip about Django REST framework, Django

Avatar of tabbott
Founder at Zulip ·

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.

5 upvotes·4.4K views