https://htmx.org logo
Join Discord
Powered by
# 🔥-django-htmx
  • h
    oh that's a neat app
  • h
    Mangum is new to me, I'll check that out
  • p
    Hello there! 🙂 I'm new here.
  • a
    Hi and welcome @User! 👋 Oh boy did you luck out - the django htmx part of the community contains some of the most prolific power users of htmx 😁
  • p
    How exciting. I'm coming from SPA frameworks and languages like Angular, React and Elm. Worked with Django a number of years ago and recently picked it back up because of htmx and the ideas of rapid prototyping full stack applications
  • p
    Sounds like a good suggestion, I'm running DO and it gets a bit pricey, so might be worth checking alternatives.
  • f
    Hetzner scums kappa
  • f
    What does it do? I never quite understood using a full blown MANIFEST etc instead of just using a 
    docker-compose
    with auto-deployment via 
    git pull
  • b
    It deploys to Heroku or Azure. Listening to the podcast he just wanted to have an abstraction layer for deployment
  • f
    What's wrong with 
    git pull; docker-compose down; docker-compose up --force-recreate --build
    aka 
    systemctl restart snowflakeWebapp
    ?
  • f
    Looking at the code I just don't feel like it's much of an abstraction but rather a bit over-engineered^^
  • p
    Do you mean Heroku in general or this abstraction layer in particular?
  • f
    The "abstraction layer" in particular. But Heroku seems quite useless to me also – now that you mention it, unless you're unwilling to spend the 3hrs it takes to learn some ops
  • b
    So he has written a book and felt like the deployment chapter was a little too step-by-step and Heroku-specific. Plus basically doing Heroku’s job for them. So he decided to have something that can deploy from the CLI to The Cloud ⛅️
  • f
  • f
    I see. That makes sense I guess. But why not just use 
    docker-compose
    ?
  • p
    Sure, but I guess someone using Heroku isn't just running their web server, they'll be using e.g. PgSQL buildpacks with auto backups etc. Yes you can do all of that yourself but if you're a one-person SAAS with limited time, it's not the worst thing.
  • f
    What about pointing DNS to it? Surely you don't want it to be called myapp.herokuapp.com the whole time. Honestly looking at https://www.heroku.com/pricing & trying to figure out each tier you need, you might as well figure out deployment yourself lol
  • p
    Sure, but it's not just deployment but things like managed databases. Not saying Heroku is the best solution & if you have time & skill to set it all up yourself, fine, but it's a viable solution in some cases (can get pricey though).
  • p
    There are probably better (and cheaper) things out there these days if you want that e.g. Digital Ocean managed dbs, whatever its called in AWS etc.
  • p
    Heroku's OK for the free tier if you want to throw something quickly over the wall for a demo, but probably render or fly.io are better nowadays.
  • f
    Gotcha. Thanks for clarifying. However imo it feels like a cheap excuse people make up because they hear "Django is a pain to deploy", in order to not invest in their own human capital – especially for something I would consider quite fundamental
  • p
    Yeah with containers Django is no harder or easier than anything else these days. To paraphrase Homer Simpson, "Docker is the answer to - and the cause of - all our problems".
  • f
    kappa
  • f
    Definitely true when you combine it with Kubernetes
  • b
    I’ve been looking at bundling a venv in a deb package then using systemd. But I’ll do a lot of work to avoid k8s
  • p
    Crazy number of job postings I'm seeing these days with Kubernetes in there somewhere
  • p
    "We run Kubernetes on EKS". "How much traffic do you get?" "About 200 users a day. But we need to scale!"
  • b
    If you’re trying k8s then you have to try tilt.dev
  • b
    Really reduces the reload time for changes.
1...505152...100Latest