They are useful for links that need to outlive the infrastructure they are hosted on. Think about them as a layer of abstraction. Ie. Links in paper published to a journal like nature. It might be valid for 10 years but the links embedded in it will rot quickly as organisations change cms's, domains names change. Organisations merge and disappear.
Also places where the cost to change the url is expensive, bus shelter adverts etc.
I think this is important but also hits the trust problem: open shorteners are basically training users to be phished but a controlled namespace doesn’t have that problem. Ideally you can use a domain you control for everything to get full control of your reputation while still retaining the flexibility to redirect links as needed.
If you had the time and inclination you could even seed their account with mock stat's. I.e. when the link shortened is accessed, correctly log all of the metrics to their account so they have solid metrics indicating its working, but fail the actual consumer requests
Logging their metrics correctly is going to take resource. Instead, just set a flag on their account which, if true, means they just see some randomised junk stats.
Really, you use testcontainers so that you can manage everything for your test with a single build command, instead of running something extra, then running your tests, then shutting down your docker containers. Plus, with it integrated into your test suites, you can run code against your docker containers on setup/teardown, before/after container start, before/after each test, etc.
Meanwhile docker compose selling point: 'because you don't have to muck around with testcontainers; I guess some people might find that more attractive'.
Oh, absolutely! And as the other guy pointed out, docker-compose can be quite reusable when developing locally if you write it right.
But at $WORKPLACE we often use pytest-xprocess to start the required app in the same container where the tests run. It's probably the easiest way mostly because a custom wrapper does all the heavy lifting (starts the app, checks that it is running and responding to requests before the tests start, correctly terminates it when tests end).
This looks to be like just language specific bindings over the docker compose syntax. You're right that docker compose handles all of the situations they describe.
The major issue I had with docker compose in my CI environment is flaky tests when a port is already used by another job I don't control. With testcontainers, I haven't seen any false positive as I can use whatever port is available and not a hardcoded one hoping it won't conflict with what other people are doing.
Unless I'm mistaken, this is only a problem if you're forwarding ports from the Docker containers to the host machine, which isn't necessary if the test itself is running from inside a Docker container on the same bridge network as your dependencies. (Which compose will set up for you by default.)
Yes, I felt the same, I thought I was unaware of some fundamental flaw of webhooks.
I feel webooks have lasted because they are the simplest thing that gets the job done. They only rely upon open standards like http, they are secured via tls, have well understood failure scenarios.
I was being a bit contrarian. Obviously choice of tech stack is important. But, in my experience, people obsess too much over that and sepnd way too little time thinking about marketing. Also, choose reliable 'devil you know' tech over the latest flashy framework.
File formats like CSV will outlast religion.