odykyi

Migrations in the API's start script feel convenient for about a week. Then two replicas boot at once and one of them wins a race you didn't know existed. Give them their own step that runs once.

Hot reload is great until the thing that needs reloading is the service next to yours. Then it's a restart you forgot to do and ten minutes of "why is my change not showing up".

Weird thing I noticed: the apps I never get around to fixing are the ones that take more than one command to start. Friction doesn't just cost time, it decides what gets maintained.

Nobody tells you that ports are the real config of a local stack. Three services, each with a "random free port" fallback, and suddenly you're grepping for 3000 at 11pm. Pick ports once, write them down, never think about it again.

Seed data is a feature. The day a new teammate can see a realistic app in five minutes is the day your onboarding doc gets shorter by a page.

Debugging a multi-service app is 20% reading logs and 80% figuring out which service the log came from. One merged stream with service names on every line fixed more bugs for me than any tracing tool.

Small rule I've stuck to: if a service can run as a plain process, it doesn't get a container. Docker is for the things that really need it, like a database or a queue. The rest just runs.

Hot take after a year of microservices on a laptop: the slowest part of the inner loop is never your code. It's the 40 seconds between "I saved the file" and "I can see it run". Cut that and everything else gets easier.

tiny apps don't need Docker. if every service in your service.json declares a command, flisk runs them as plain local processes. no containers, no Tilt. a two-service menu app is up in about a second.