yeah that matches what I see, most of what we run at work is one app and one database, so the slow query log plus looking at the plan gets you like 90% of the way. I never really had the multi service case where otel pays off, I guess at some point it does, but for a small team it felt like a lot of plumbing to end up finding the same n+1 query lol

I’d add that most of the time nobody actually measured anything. at work we inherit slow sites all the time and the first guess is always “the stack”, then you profile it and it’s one query running per item in a loop or something like that. I had the same with my own side project, was sure I needed a bigger server and after measuring the problem was somewhere else completely. measuring first is boring but it’s cheaper than any rewrite I guess

on the fear part, in a healthy team the author still owns the change, the reviewer is a second pair of eyes not an insurance policy. what helped my people a lot was asking the author how they tested it and what happens if it goes wrong, if they can’t answer that’s your review comment right there. and if something breaks after you approved it, you fix it together and add a check so it doesn’t happen again, nobody serious blames the reviewer for that

Interesting idea, but in my case it would feel worse I think, each paint costs a charge, so undoing both means two people lose a charge and nobody gets the cell. I don’t think it happens much at our size anyway, two people on the exact same cell inside half a second is pretty rare. last write wins is a bit unfair but it’s simple, and since every write is stored you can always see who painted what

Same conclusion here from the other side, I have a small multiplayer browser game where everyone paints cells on one shared grid (node, postgres, SSE), the client applies the paint right away and the server either confirms it or answers with a 409/429 and the client puts the old cell back. the rejection part is the one that took me longest honestly, a mutation that is valid locally but the server says no (out of charges, same color already there, world paused) and you need a different message for each, otherwise people think it’s lag. conflicts are just last write wins per cell, but that works because every write is a row in an append only events table, so nothing is really lost and you can replay or undo. and on reconnect I don’t try to merge anything, the client asks for the whole state again, at that size it’s cheaper than being clever.

for a multiplayer browser game I ended up skipping websockets and using SSE for everything that goes server to client, and plain POST requests for the actions. it’s just http so the reverse proxy, cookies and reconnects work without doing anything special, and EventSource reconnects by itself. one gotcha if you use express with compression middleware, exclude the SSE route or the events get buffered and arrive in chunks. websockets make more sense if the client sends a lot, mine mostly listens

For me the evidence was the server logs, filtering by user agent. my main page is basically a canvas game, so the html has almost nothing for a crawler, and I was surprised to see googlebot not only rendering it but opening the SSE stream like a real player (I noticed because bots were showing up as online players lol). what actually got indexed were the plain server rendered pages I made for each thing worth sharing, with title, og image and json-ld, listed in the sitemap. so I didn’t change the app rendering, I just gave crawlers simpler pages to read.