I've had some PRs that would have required a ton of comments. There are usually two ways I handle this:

If the PR went in a completely different direction and missed the goal by a lot, I take ownership of it (with a brief explanation) and re-implement it. I then use the new PR for a pairing session, where I walk through both PRs with the original author for learning purposes.

If it’s mostly smaller issues, I schedule a half-hour pairing session with the author and review everything together, after preparing a list of issues.

Doing it any other way puts too much burden on the author to guess what the reviewer wants, and it slows down velocity significantly.

Next time tell him that if he isn't going to provide something constructive to the meeting, that he won't be allowed to join further ones.

As long as you make it clear from your tone and wording, that this is not you being aggressive in any way but you protecting the time of the team from distractions, the rest of the team shouldn't see you any different than before.

Don’t do this in front of the team. This sort of message should be delivered privately.

Doubt this is the way to go anyway but it’s definitely not something to say during the meeting.

Worst thing is that the team dynamic gets even worse, the guy becomes bitter and impossible to work with, and management punishes you for unprofessional and inappropriate behavior.

Not sure couldn't it just have been multiple different tokens/sessions and based on the request, use the correct one? It obviously only solves the issue specifically for multi-tenancy, but if that meant being able to stay on RBAC and well, not doing that effort, I'd wager it'd be worth the trade-off

Couldn't this be done in some way when validation exists, that the same validation is used to create a "better" placeholder value that may be able to be used with specific conditional functions? (eq(), includes(), etc.)

I'm wondering how history could have been if Hitler had access to nuclear weapons / empathy given by a super power.

This is a step forward, but what's the way forward?

Well, CloudnativePG exists and it works really really well. At some point if you can afford to have someone manage your databases separately from your applications, you can think about putting it outside the cluster but I'd wager at some point you've got enough experience with running your DB with an operator that you can keep running it in the cluster.

You'd have to reach the same instance for your next request. Easier to just tell clients that they get returned a header that they should attach to their requests so the backend can route their reads to the primary for some time until replication caught up.

The trick is to not worry about useMemo and useCallback because it's rarely an issue unless you have 800 line components or don't compose but rather treat everything as if it was inheritance.

I've got pretty sizeable codebases, less than 5 useEffects ever (nowadays I only have one for a single location where I need to manually poll, the rest is useSyncExternalStore) and I only do useMemo for tables.

Compiler is just an additional performance improvement that's "free" and at least the compiler doesn't make it harder to understand how your code executes because it just works

I'd rather break my hands than use Svelte instead of React again. It comes with so many problems of itself. Summarized in a single sentence though it would be: It's more common than you'd like it to be, that your UI doesn't actually reflect the state of your application.

I was considering investing in learning Svelte to avoid some of the React quirkiness, but this is not very promising. Can you share a bit more? Trading off a set of quirky annoying things for an equivalent or worse one would be suboptimal.

Svelte promises to be better than React but in the end it is not - and I hate React. React is a world on its own inside the frontend and Svelte did exactly the same, it is just different unnecessary complexity. And they even change everything every couple of years just like React.

I'm not sure what you're actually trying to say by that. Svelte has fine-grained opt-in reactivity. If you don't declare a variable with $state, it won't be reactive. That's by design and not a problem.

Too bad that the Supertokens docs became an absolute dumpster fire with their "recipes" and reading the source made me lose confidence in the product's quality to rely on.

Not saying better-auth is strictly better, but at least you can read the docs and know what you're getting into yourself instead of 12 variations of the same thing