I don’t know how dead it is, but it’s pretty straightforward to set up your own gateway (public or private). Even if you don’t have a tech background, there’s the “IPFS Desktop” app that stands up the IPFS service locally.
I don’t know how dead it is, but it’s pretty straightforward to set up your own gateway (public or private). Even if you don’t have a tech background, there’s the “IPFS Desktop” app that stands up the IPFS service locally.


The only one I think is reasonable is GraphQL. But that isn’t rest, and HTTP is just one of the transport layers it supports.
For anything claiming to be RESTful, it’s a crime.


Two different concepts.
You’re talking about work slowing because of increased overhead from more people needing to communicate and make decisions.
The OP is talking about the"bus factor". How many people can leave the project unexpectedly and still have the project survive. E.g. if only one person has access to merge changes, the bus factor is 1 regardless of how many people actively contribute.


(another pet peeve of mine is “rest” APIs that use 200 response codes for everything)


Yup, also some APIs use GET for everything. It’s a pain. And it means that filtering by verb only helps if you’re intimately familiar with the API. And even then, only if you keep up with changes as they happen. So really, only if you’re developing the API yourself.
In an enterprise setting, you shouldn’t trust the server firewall. You lock that down with your network equipment.
Edit: sorry, I failed to read the whole post 🤦♂️. I don’t have a good answer for you. When I used docker in my homelab, I exposed services using labels and a traefik container similar to this: https://docs.docker.com/guides/traefik/#using-traefik-with-docker
That doesn’t protect you from accidentally exposing ports, but it helps make it more obvious when it happens.