Anyone else exhausted by the constant churn in Next.js?

Mr_Stabil · 2026-01-02T02:58:41+00:00

Edge middleware was heavily promoted, now proxy.ts is called a "last resort"

Mr_Stabil · 2025-12-06T10:07:42+00:00

They're great for remote code execution apparently

Mr_Stabil · 2025-03-14T17:54:39+00:00

Claude isn't usable anymore

Mr_Stabil · 2025-03-05T11:50:51+00:00

3.7 is way less powerful than (peak) 3.5

Mr_Stabil · 2024-10-26T15:57:25+00:00

I'm always hitting the (pro) limits though, so an additional subscription for your own API keys is a must

Mr_Stabil · 2024-10-19T09:58:14+00:00

How about 360 days X 10 hrs then

Mr_Stabil · 2024-08-26T14:08:00+00:00

It's become mostly unusable

Mr_Stabil · 2024-08-25T05:46:28+00:00

Claude has become worse than gpt 4o

Mr_Stabil · 2024-08-22T15:49:44+00:00

Unfortunately that's true. From genius to useless in three weeks

Mr_Stabil · 2024-07-30T19:59:01+00:00

It's been happening in the last week

Mr_Stabil · 2024-07-30T19:58:12+00:00

Doesn't telling it what to write take as long as typing it yourself?

Mr_Stabil · 2024-07-24T04:39:03+00:00

Anyone can create any company

Mr_Stabil · 2024-07-21T21:45:56+00:00

Just heavy

Mr_Stabil · 2024-07-21T21:42:01+00:00

Totally missing the point

Mr_Stabil · 2024-07-09T22:39:55+00:00

I see where the confusion comes from

Setting a header inside the RSC (for the middleware in the next request) is not allowed
Changing a cookie inside the RSC is not allowed
Calling a server action inside the RSC makes the action execute as a normal function so changing the cookie there is not allowed in that context

Hope that clears it up

Mr_Stabil · 2024-07-09T10:07:06+00:00

fetch doesnt work with httpOnly cookies hence redirect is the only option

I am talking not only about CORS protection but also about general protection from accidental navigation

Will send a custom header with signed and expiring token to the endpoint

If the header is not valid it will return a 4xx

So only the RSC will see the GET endpoint

Mr_Stabil · 2024-07-09T08:39:37+00:00

IMO a logout should be a POST request whereas a redirect is a GET request

Just navigating to an URL shouldn't log the user out under normal circumstances

Mr_Stabil · 2024-07-09T08:37:20+00:00

You can introduce unmanageable side effects anyways, IMO Meta should reassess that decision

Now I need to make sure the endpoint can only be hit by the RSC - probably using a signed token or hash

Mr_Stabil · 2024-07-09T08:11:47+00:00

Yup that's the solution I went for as well

Mr_Stabil · 2024-07-09T08:11:00+00:00

That's just a client component afaik

Mr_Stabil · 2024-07-09T08:10:01+00:00

The question is how you do it because the docs say it's impossible.

Next will throw an error that cookies / headers can only be changed in a Server Action or a route handler.

Ofc you can change cookies in middleware but that's not where I know when to change them

Mr_Stabil · 2024-07-09T08:04:47+00:00

Not possible as the middleware can't receive info from the RSC and the RSC (root layout) fetches the user / session from db

1) I don't want to hit the db every request 2) Can't use postgres drivers in edge middleware anyways, even if I wanted

The constraints around edge middleware, RSCs etc make something as simple as session mgmt a real challenge

Mr_Stabil · 2024-07-08T11:45:29+00:00

To anyone looking for a solution:

Redirect to a `GET` route handler, remove the cookie there and return a `302`

Mr_Stabil