IntercoolerJS / htmx looks like a really cool solution for server-side rendered HTML with client-side interactivity. All the hype is currently with https://hotwire.dev/ but htmx has more features, seems more solid and even supports older browsers like IE11.
There is a Discord for HTMX and Intercooler (another one-developer-show) https://htmx.org/discord
> another one-developer-show
In addition to the founder, there are at least 3 active contributors with significant contributions to HTMX. It may have started as a one man show, however, the knowledge is now spread over quite a few people who are exceptionally helpful.
I don't get why people use Docker for "small SaaS apps" where "scale is not an issue". You can run everything without Docker to remove an extra level of indirection. I've been doing that exact thing with a very similar Django stack for years. Not once have I missed Docker. On the other hand, I have taken over SaaS projects where the (unnecessary) usage of Docker made it more expensive to host, decidedly more difficul…
> usage of Docker made it more expensive to host It depends on how you're using it. Docker itself isn't going to increase your hosting costs. If you rent a server for $20 a month, it's still $20 a month with or without Docker being installed.
What you usually can't avoid though is that you have to account for much bigger disk usage for the image storage - both on local and target machine.
I don’t know. I keep seeing this argument. I’ve been developing on the Django stack for the past 10+ years. I have fixed many bugs if mine and of others. It has been extremely rare, if at all, that they were bugs caused by an incorrect type. The closest I can think of is a typo in a method or class name, but is it really a bug if you catch it instantly? These are just not the types of bugs that end up creeping into t…
Has Django's ORM syntax changed recently? If not, this is the first time I've heard someone say it's a pleasure to read/write. I've done lots of Python over the years (Zope3, Django, flask, aiohttp, custom stuff...), and if there is one thing I wouldn't like to come back to, it's Django. Sure, it's a do-everything toolset, but the syntax is an abomination (imho, at least, though I hope that doesn't need to be stresse…
It has not but it has expanded and been polished up. I used to be pretty anti-ORM because I felt like they were leaky incomplete abstractions. Having used SQLAlchemy for a major project in the past (used it on top of Django instead of the built in one) and then coming back to Django’s, I can say that Django’s is to me easier and nicer to use. The performance is now on par with the SQLA declarative implementation. I never really loved the core implementation for being as verbose as it was. I would rather write SQL directly at that point.
About the only place where I dislike Django’s ORM is stuff around aggregation and annotation. The fact that the order in which you declare your annotations matters is annoying af and while I understand the need for it, I do wish there was a better way. Having said that, I have simply started structuring my models in a way that doesn’t require complex aggregation and that made my life a lot easier. If I have an instance of a Book model I know what fields to expect it to have and don’t worry about whether this particular time it has some specific annotation attached to it or not. That has made the rest of the code a lot cleaner.
Basically, I think to each their own, but I don’t see the Django ORM as a negative. Give it a try and see how it works for you especially if you can avoid going against the grain with it.
the issue I had with this setup is that without a systemd or any daemon you might need to firefight and manually restart your containers each time there is an issue
I don't get why people use Docker for "small SaaS apps" where "scale is not an issue". You can run everything without Docker to remove an extra level of indirection. I've been doing that exact thing with a very similar Django stack for years. Not once have I missed Docker. On the other hand, I have taken over SaaS projects where the (unnecessary) usage of Docker made it more expensive to host, decidedly more difficul…
I'm not trying to pick on you personally here but this comment, like many I see on HN, seems overly adversarial and could have made the same arguments in a less combatative way. There's a lot of emphasis on your own perspective: "*I* don't get", "*I've* been doing that", "Not once have *I* missed Docker", "making *me* less productive", "*my* personal experience*" And an assumption that it applies to others: "Just use…
I understand your concern and agree that I am being extremely direct. It's not out of spite. On the one hand, it comes from my frustration with what I as an engineer perceive to be wrong advice. It feels to me like OP is using Docker because he read a blog post about it somewhere, never seriously thought about alternatives, then stuck with it and now recommends it to others, repeating a cycle where software gets worse and worse. And on the other hand, being direct is more concise. We all have little time and I feel that to get a point across on the internet, one has to get it across quickly and succinctly. I have no problem with my views being criticised and I'll be happy to concede where I was wrong if someone makes a clear and harsh point. But either way, I'm sorry if I offended you in particular or others who did not comment; It was not my intention. Having read this thread, I think much of the difference of opinion comes from different contexts. People who like Docker often seem to be working in larger teams, which is totally fine and they're probably right to use Docker. I just couldn't help but disagree with a statement that I felt pertains to an area I work in, which is small SaaS of tiny teams with usually no scalability requirements.
I don't get why people use Docker for "small SaaS apps" where "scale is not an issue". You can run everything without Docker to remove an extra level of indirection. I've been doing that exact thing with a very similar Django stack for years. Not once have I missed Docker. On the other hand, I have taken over SaaS projects where the (unnecessary) usage of Docker made it more expensive to host, decidedly more difficul…
It’s too fucking hard to setup python with all its pyenv, anaconda, poetry, pip requirements.txt and what-not, that’s the best use case for Docker here. Get it to work once and forget about it.
No it's not. It's literally just two commands to get started with poetry, and after that, one command to add a dependency and it's pretty easy to run simple projects locally.
I prefer my system for running youtube-dl in an isolated environment without having to install all of its dependencies on the host. Ansible writes a bash script at ~/bin/youtube-dl containing: #!/usr/bin/env bash set -e IMAGE_NAME="grepular/youtube-dl" # Build the image if it does not exist if [[ $(podman images --filter "reference=$IMAGE_NAME" -q) == "" ]]; then podman build -t "$IMAGE_NAME" - &2 FROM python:3-slim…
QQ, aren't the created files owned by root?
Nope. I'm using podman rather than docker so they're owned by the user that runs the script. The root user isn't involved. If I were using docker, I'd add `-u "$(id -u):$(id -g)"` to the docker args to deal with that issue.
Thanks for the kind words. I should update the part about the queues. I started using this pattern for SKIP LOCKED and it works well for multiple workers (search engine crawlers). https://www.2ndquadrant.com/en/blog/what-is-select-skip-lock... And implemented in Django: https://docs.djangoproject.com/en/3.1/ref/models/querysets/#...
I instantly thought of something similar when I looked at your code. I like the simplicity! I used to combine RabbitMQ and Celery for async tasks. Mostly because it's what I learned to do since it was already in use at my first job. But Celery is such a pain -- or, at least, it was at that job. So many configuration options, different places where they were stored in different versions[1]. Weird errors. Poor document…
Interesting that you talk about gluing together some things around docker-compose. I've done something similar but on the command-line. Specifically, I use Makefile as a task-runner [1]. It is in there that I keep a lot of my custom settings for deployments, hosts, and one-off taks.
Everything you write is possible, but - and again in every single step of your daily dev work - more tedious than doing things directly. It's just not worth it for me. But it also sounds like you are operating within a larger organization. So your requirements may be different from mine.
It's not tedious at all and it saves potentially blowing up your system with crap splattered all over your filesystem. We have tons of WSL2 devs and Linux people and it takes care of the, "it works on my machine" problem once and for all. This insistent push that the old way was good and why did we expend all this effort to make a new thing that I don't want to bother learning the five new invocations to just doesn't…
I echo this sentiment entirely.. mutli dev-environment, multi-machine / os things really just work. Docker et al also really shines with onboarding, the new recruit can literally get up and going in minutes.
I would not want to go back to the old ways of doing things.
> I don't. I just use one $5 per month Linode for each SaaS Well then you're basically using VMs as your containerization mechanism, with install scripts replacing Dockerfiles. So from your perspective, don't think of Docker as a really fat binary. Think of it as a stripped-down VM that doesn't cost a minimum of $5 per instance, and comes in a standardized format with a standardized ecosystem around it (package regis…
It's a really fat binary that adds unnecessary layers in both dev and prod. In dev, it's faster to run tests and easier to debug without Docker. And in prod, why use a vm inside a vm?
Containerisation software adds so much more than just a binary with layers of indirection.
Easy fine grain control of individual application memory, namespace isolation (container to container communication on a need to know basis), A-B testing, ease of on-boarding, multi-os development, CD pipelines, ease of container restarting etc.