←back to thread

Happy 20th Birthday, Django

(www.djangoproject.com)
578 points davepeck | 5 comments | | HN request time: 1.146s | source
Show context
ghc ◴[] No.44560305[source]
In a very real sense, I have Django to thank for my entire career. As an undergraduate, my first academic job in a research lab had me building websites to promote the research in a lab. Django was brand new, and I was uninterested in petty concerns like stability and security, so I did everything in Django.

Years later (2009), I got to do interesting work in a cutting edge machine learning lab due to the expertise I developed in Django -- I was accepted into the lab specifically to clean up the mess phd students had made trying to build a complex front end using Django's ORM with physically separate per-user MySQL database servers.

All the things that came after -- being the first full time employee at a machine learning spinout from the lab, getting acquired by a big company and scaling up sensor-driven ML in the real world, quitting to co-found an ML-centered VC fund, starting a (now 10 year old) AI company -- none of it would have happened without Django.

replies(6): >>44561151 #>>44561412 #>>44563386 #>>44563464 #>>44564425 #>>44566069 #
1. tough ◴[] No.44563386[source]
> trying to build a complex front end using Django's ORM with physically separate per-user MySQL database servers.

didnt they hear about sqlite, great for this setup

replies(1): >>44564511 #
2. ghc ◴[] No.44564511[source]
I don't think Django could have talked to sqlite over the network, or would have really solved any problems. When I say physically separate, I mean it in the pre-cloud sense: one front end server (Django) dynamically connecting to a database on a remote server (based on the user account), which had a database continuously logging streams of sensor data from local IoT devices.

What I did was change the architecture to support centralized aggregation in a large co-located Postgres server, implementing security to managed permissions for writers (sensor gateway) and readers (user accounts).

Eventually we had to write a pg backend similar in concept to timescaledb to handle the massive scale of sensor data we were ingesting...but that's another story entirely.

replies(1): >>44565709 #
3. Induane ◴[] No.44565709[source]
Django has supported database routing for ages. I've abused it for setups like yours (at least as I vaguely understand from the post details) to avoid using a datalake
replies(1): >>44571727 #
4. ghc ◴[] No.44571727{3}[source]
It was added over a year after we needed it (back in 2008/2009). I'm pretty sure our use case was taken as an input into the design of Django's database routing. We were certainly loud enough about it.
replies(1): >>44577460 #
5. Induane ◴[] No.44577460{4}[source]
Haha well in that case thanks!