i think nginx has an oauth_module which would allow you to use something like keycloak, if you want more than basic auth.

for apache mod_auth_openidc exists.

setting up an oauth-provider is not exactly trivial, but well documented and could be worth it if your other services offer oauth2-support or don’t feature a login at all.

for many people homelabbing is a way to gain knowledge they can use on the job.

other than that: proper single sign on across your services is nice even if you don’t expose them to anybody else.

i code using a german layout and to type any kind of bracket you have to use a modifier key and a number. its awkward, but i am to lazy to switch between layouts and sometimes work on machines where i can’t change the layout easily.

python is quite nice to programm on a german layout, because it tends to have fewer braces than other languages.

tl;dr: german keyboard layout “hides” many symbols on a second layer beneath the number row which makes it awkward to use for many programming languages.

most flexible api-testing-tool

i’ve tested postman, bruno, insomnia and countless things i forgot, but in the end i’ll end up with some bash scripts and curl.

hey, the 24 hours i invested were totally worth it to save 30 minutes of work over a year!

no, user data is not federated accross instances.

knowing where something happens is not knowing what happens and especially not knowing why it happens.

A big import of data caused a specific datapoint to be inserted twice into the database, but that only happened in our shared testing environment not in our development environment, logs made it clear that we tried to insert something twice into a join table but not why.

the fix was easy, we can remove the duplicated datapoint from our data before writing it to the database, and we found an edgecase we can handle further upstream so we don’t end up duplicating it in the first place, but why didn’t we run into this issue in dev?

the data is consumed from a kafka topic with a single partition and read order is allways the same as write order, so our service behaves the same way if the same data is written to the topic everytime, but it turns out the producer does not necessarily write in the same order to the topic given the same input and gaining that understanding was a goose chase with debuggers, logs and combing through code of multiple services written by multiple devs working at multiple companies and thats the true horror of enterprise development jobs, teying to get someone from a different team or even company on the phone who can actually explain something to you with whom you can analyse a bigger part of a system.