– The history of Real Python and how Dan ended up taking over

– Replacing a PHP back-end with a custom Django app from scratch

– Dan is the sole developer but he wants that to change soon

– Django has been a happy developer experience and it’s very effective

– Motivation for switching to Django and a break down of Real Python’s features

– Dan tries to keep the code base on the latest stable Django release

– Real Python has been using Python 3.x from day 1

– Staying up to date often takes effort, but it saves time in the long run

– Automated and manual ways to keep your dependencies up to date

– Real Python is mostly a monolithic application by choice

– 19,000+ lines of Python code spread across ~23 Django apps

– A high level break down of the Django apps

– The challenges of trying to break up your apps too early in the dev process

– Server side rendered templates is allowing Dan to be quite efficient

– Django was specifically built to display documents (news articles)

– Real Python uses the built-in Django admin and it’s working great

– Multiple ways to have an admin back-end without an admin dashboard

– The site doesn’t use Django channels or any type of websockets

– Docker is being used locally for development but only partially with Docker Compose

– The Python app is not using Docker mainly due to volume performance issues

– But all local tests are run inside of Docker (even the Python app)

– Dan wishes Docker were faster on MacOS, it would be nice for other developers

– Huey is being used instead of Celery for background tasks

– Huey even supports running periodic scheduled tasks on an interval

– You might need custom code to deal with retries and guarantees

– There’s a lot of responsibility to make sure Real Python stays up

– Dans likes Heroku because it’s easy to get notified of availability issues

– Papertrail provides log access and alerts him over Slack on errors

– For up time monitoring he’s using Freshping

– All errors and notifications get piped to Slack to keep it easy to glance

– What happens if Heroku or AWS goes down? You kind of have to deal with it

– The “up-time value” in building a custom platform / app for your content

– Payments are handled with a reseller called Paddle, they handle taxes and more

– They take a few percent more than Stripe but it’s worth it for Dan

– Dealing with taxes is very complicated and soul draining

– Sometimes these services end up being better on all fronts (even price)

– Paddle supports credit cards, PayPal and Apple Pay through 1 API provided by Paddle

– SendGrid is being used to send out all types of email from the platform

– SendGrid’s batch API endpoint lets you send 1,000 emails in 1 API call

– CloudFlare is being used to convert images to webp (image re-compression)

– CloudFlare (he’s using the paid plan btw) also uses HTTP / 2 in supported browsers

– It also helps with rate limiting because Real Python has been getting attacked

– SSL certificates are handled with CloudFlare and Heroku together

– Real Python is using gunicorn

– How Heroku deals with running and configuring gunicorn

– (4) standard-2x Dynos and (1) standard-1x Worker powers the whole site

– CloudFlare’s CDN helps to offset the dyno’s load by serving all of the static files

– Static files are initially served by WhiteNoise for 1 request then CloudFlare caches it

– A tiny microservice proxy called RuboCrop resizes images to different sizes

– Lots of images and articles require alternate ways of organizing things

– There is a full text search feature built into the site but it might not be enough

– The Heroku add-ons being used are Postgres, Redis, Scheduler and Papertrail

– Hosting costs on Heroku is about $700 / month (including a staging environment)

– It’s totally worth it for Dan, the value he gets is massive

– As a solo developer you need to think about the time vs money vs sanity trade off

– Walking though a code deploy from development to staging to production

– Heroku’s metrics dashboard makes it easy to rollback if things look off

– 1 person code reviews are awesome and it allows for scaling up devs later

– Heroku handles database backups and user uploaded files are sent to S3

– Dan thinks he can rebuild everything very quickly if disaster struck

– Vimeo is being used to host videos and provide the video player

– Best tips? Embrace the golden age of the solo web developer being viable

– It’s so easy to initially get caught up in building something super difficult

– One of Dan’s biggest mistakes at a previous company was going microservices

– Before it was released Real Python ran on WordPress but Dan decided against it

– Philosophically it kind of sucks to have a big Python site running on PHP

– Building your own tutorial platform helps you come up with tutorial content

– Find Dan on Twitter @dbader_org and his personal site. You can also find Real Python on Twitter, YouTube and Instagram as well as realpython.com