Modern react developers forget that if statements exist. When react was class based it was trivial to do:

  render() {
    if (this.dontNeedToRender) {
      return null
    }
  }

Now, because hooks can't be skipped, react developers jump through many hoops to use an if statement during rendering.

I might be missing your point, can you elaborate? If you want to write an if statement you just do it at the end of a component, after the hooks. It's a common pattern.

If you don’t use `async def` and you are using fastapi it’s easy to accidentally block the event loop.

> it’s easy to accidentally block the event loop.

Can you share a scenario where this would happen?

I have deployed multiple machine learning and data analytics-focused web services, and this has never happened to me.

Well, you can even block event loop in `async def` if you are not careful. When you are using `async def` you need to do all your IO (disk, network) operations asynchronously or your are blocking the event loop.

With a for loop? You probably don't know you are, or just aren't doing anything cpu intensive.

April fools?

> this is not something an engineer tasked with fixing an outage should be making the decision on

I don’t get this at all.

I’d much prefer a team of highly empowered and highly responsible engineers than impotent engineers who need hand holding in case they make a mistake.

Well, good thing that wasn’t what I suggested.

Engineers _should_ have leeway in how they resolve issues. As I read, though, you have a company policy which explicitly disallows the action you needed to take to fix the problem (if I misread, my apologies). Getting the stakeholders involved is the responsible thing to do when policies need to be broken.

Ideally, the way this kind of situation gets handled should be documented as part of a break-glass policy, so there’s no ambiguity. If that’s not the case, though, the business should get to decide, alongside the policy maker (e.g.: security), whether that policy should be broken as part of an emergency fix, and how to remediate the policy drift after the crisis.

If you’re all tight enough that you’re allowed to make these kinds of decisions in the heat of the moment, that’s great, but it should be agreed upon, and documented, beforehand.

Maybe.

There’s also folks that pair because they’re a crutch for one or two other engineers. The other engineers never improve or are let go, but softly slow down the team.

There’s also the folks that pair because their code doesn’t make sense on its own. Or they have some config files they’ve refused to check into the repo, etc.

Pairing makes them feel valuable.

> There’s... folks that pair because they’re a crutch for one or two other engineers [who] never improve.

I can imagine this happening if neither pair is all that good a communicator, and if the seniormost never employs a little Socratic dialog every now and then.

That’s not a good excuse

It's not even an excuse.

Why shouldn’t middleware be responsible for access control?

That should be the server. Your Nextjs app should have zero access to business data without at least an auth token. And if you're relying on middleware for auth, it'll be responsible for providing that auth token to the rest of the app. And if you bypass middleware, then there's no auth token, and no vulnerability.

This is only a vulnerability if you have pages you don't want to render for some people, regardless of upstream data it would need to fetch.

Not necessarily. There is no big difference whether the business logic resides in the same node process or another one. If the first process is unsafe on that level, then the token can also be extracted.

Middleware runs server side doesn't it? tbh I haven't used nextjs middleware. But in many frameworks have used middleware that provides overarching access control.

For example having all routes under `/admin/*` automatically return an error if the user is not an admin, and then the individual routes don't need to be concerns with access control.

The issue is, everyone uses middleware because Next.js doesn't provide a primitive for a middleware like how it's done for any other framework. Just something to execute before your endpoint, that's it.

They haven't had one for years and everyone wrapped their endpoints which was error prone and also flat out annoying, it's reasonable that people then jump to middleware

Engineers that only rely on docs never reach their full potential. Reading the source is a must.

I think junior devs often don’t realize they should be reading the source of the libraries they use.

That is an important catalyst aggregating the problem. Juniors are reading less code, mostly generating and then AI code produced dissuades them from reading code even more and the skills take a bit even more.

It wasn’t clear to me what “u’re” was and I wouldn’t have understood without the comment. I’m a native English speaker.

Wasn’t the guy who wrote “all correct” as “oll korrekt”[1] a native [American] English speaker also?

—-

1. https://en.m.wikipedia.org/wiki/OK

Not to contradict you, but fascinating coincidence: my favorite alleged originator of OK — "Old Kinderhook," Martin Van Buren — is to date the one and only U.S. president who did not speak English as his first language.

(But "oll korrect" is apparently attributed to Andrew Jackson, who was a native speaker, yes.)

I replaced my chromecast with a wiim pro earlier this year. So far the wiim is just as reliable and hassle free.

Looks like it is only for audio though, right?

Nice that it's not Google so with video could be a good replacement.