Heroku Connect is written primarily in Python using Django. It's an add-on and a platform app, meaning it's built on the Heroku platform. Part of our interface provides users with a realtime dashboard, so we decided to take advantage of socket.io and node.js for websocket communication. But like all Heroku apps, only one type of dyno can serve traffic. This left us with two choices: manage 2 apps, each with its own repo, and carefully consider when and how we deployed them, or find a way to serve both node and Django traffic from the same app.


Securing Celery on Heroku

engineering

Celery is by far the most popular library in Python for distributing asynchronous work using a task queue. If you're building a Python web app, chances are you already use it to send email, perform API integrations, etc. Many people choose Redis as their message broker of choice because it's dead simple to set up: provision a Redis add-on, use its environment variable as your BROKER_URL, and you're done. But the simplicity of Redis comes at a cost. Redis does not currently support SSL, and it doesn't seem like that's going to change any time soon. Because Heroku add-ons communicate over the public web, that means the contents of Celery jobs are traveling unencrypted...


Subscribe to the full-text RSS feed for David Gouldin.