Rauchg

This is super fast. Great job!

R2S was a painful one, but Lachlan was a dream of a security researcher to partner with. Not just from a responsible disclosure POV, but things like hopping on multiple calls with Meta and our team to help us validate remediations. Thank you Lachlan for helping make the internet safer (and great job on figuring out this 'labyrinth' of a vulnerability)

This was a pivotal project for me as a young lad learning Linux and software engineering back in the day. Can't recommend it enough. So many little frustrations and painpoints to overcome, wasn't easy , and shows you the ropes of what's to come.

We collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue.

We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.

Heard and appreciate the feedback. We’re well aware of the DX papercuts in Middleware. With 15.5 we made a big step in supporting Node runtime[1] which addresses a slew of issues people have reported over time.

If I went back in time, I would have called it Routing Middleware or Routing Handler. A specific hook to intercept during the routing phase, which can be delivered to the CDN edge for specialized providers. It’s also a somewhat advanced escape hatch.

Since OP mentions logging, it’s worth noting that for instrumentation and observability we’ve embraced OpenTelemetry and have an instrumentation.ts convention[2]

[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable

[2] https://nextjs.org/docs/app/api-reference/file-conventions/i...

It’s possible `/` redirects but other hidden routes phish. If someone gets e.g.: a fake password reset email, it might help the attacker bypass sanity checks users make.

Falsehoods programmers believe: the OSI model

I've been acting mostly as the 'ideas guy' and helping with the architecture / QA. It's a great way for me to dogfood Vercel and build empathy as a user in an external org, using external services.

Someone in our community created a provider and I wanted to showcase it.

It’s nice insofar with very little abstraction, runtime, and bundle size overhead, you can easily switch between models without having to learn a new API.

JS is used for fast page transitions and stuff like that, but funny enough I'm pretty sure I end up shipping less JS overall by running server-side JS.

Last I checked, a Tweet embed alone was several mbs of JS, and it causes a bunch of layout shift and loads third party resources. On my blog they're pre-rerendered and shipped statically[1]

Probably the strongest reason though is to not set a 'power cap' on your project unnecessarily. It'd suck to have to rewrite a project because you got trapped in a local maxima, which is why i always share you can have your 100 lighthouse cake & eat it too.

[1] https://rauchg.com/2021/making-the-web-faster#next-momentum

some that i've built recently with app router that are intentionally minimalistic

- https://rauchg.com

- https://next-ai-news.vercel.app/

- https://emoji-todo.vercel.app/

Next.js scales up and down in complexity / ambition. On perf:

- https://twitter.com/rauchg/status/1652093980958683137

- https://twitter.com/rauchg/status/1744183168541007878

If you have any concrete feedback on what we should improve, I’m all ears. We heard feedback from the community that they wanted better documentation and guidance on self-hosting and we shipped it last month[1]. Curious what you’d like to see improved.

[1] https://nextjs.org/blog/next-14-1#improved-self-hosting

Middleware does work with self-hosting[1]. It’s a more limited runtime that’s based on web standard APIs, which creates optionality for running it in high performance / resource constrained scenarios.

[1] https://nextjs.org/docs/app/building-your-application/deploy...

We're working on improving this and it's shipping soon!

I just had a great experience building with Drizzle ORM and NextAuth, not sure if this is helpful:

https://github.com/rauchg/next-ai-news

(This is with Next.js 14 App Router and Server Actions)

Can you tell me more about the pains you're seeing?

Always looking for the meta-feedback as well on how we can improve support. So, both pieces of feedback welcome!

Would love to dig into your support issues. Let me know: rauchg@vercel.com

I appreciate your good faith engagement and legitimate questions.

Three quick reactions:

- The employee did not find location information on our platform. Our security team is certain of this and that the system worked as intended, but the employee misused it.

- Everyone at the company takes PII and protecting customer data extremely seriously. We have and we will continue to reinforce this in light of this situation.

- Our ToS are specifically designed to protect our customers. Note that in the terms folks are discussing we mention “only in connection to providing our services”. That said I’ll be following up internally to see if more clarifications can be made (I’ve seen companies provide high level summaries in the past to help with the legalese interpretation)

Hey folks,

Some clarifications:

- Leap AI (tryleap.ai) created a template which is a demo, incomplete version of other popular products.

- Templates get submitted to the marketplace all the time. One of Vercel’s devrel promoted it. The idea is to help people learn from a realistic, complete example

- This template has nothing to do with the code or data of any existing hosted Vercel app

Happy to clarify anything else further

Turns out Vercel are trying to kill solutions like Tamagui

No one is trying to kill Tamagui. Why would we want that?

the higher ups there are investors in Tailwind

I don’t know any investors in Tailwind at Vercel. I’m certainly not one. I don’t think they’ve even taken outside investment. And it’d be against our ethical and fiduciary responsibilities to favor one solution over another on that basis.

are trying to consolidate styling around it for their own ecosystem benefit

Tailwind is a great solution that’s earned the hearts and minds of the community, and that’s why we include it as an option in `create-next-app`.

It’s an option because you can bring your own styling solutions to Next if you’d like (like yours: https://tamagui.dev/docs/guides/next-js)

Maybe your perception is backwards? Large parts of the ecosystem are consolidating on Tailwind, and it’s our job to provide sensible defaults according to that.

Indeed. We're super happy and honored to support Svelte!

So is my own site: https://twitter.com/rauchg/status/1652093980958683137

Scores need to be adjusted by and looked at through the lens of complexity. Next.js powers some of the most sophisticated web applications in the world, not just your blog and mine.

e.g.: the instant you bring "necessary evils" like display ads, your scores WILL suffer.

Good article! I always notice this same effect when I visit my parents in Argentina or I'm in Europe.

Using a global CDN can help get your assets to your users quicker, and most companies by this point are using something like Cloudflare or Vercel, but many still only serve static or cached content this way. Very frequently the origin server will still be a centralized monolith deployed in only one location, or there will only be a single database cluster.

Notably: even if the source of truth is single-region, there's a lot that can be done to improve the experience by flushing parts of the page at the edge.

Check out https://how-is-this-not-illegal.vercel.app/ where the layout.tsx[1] file is edge-rendered right away with placeholders, and then the edge renderer streams the content when the single-region database responds.

Furthermore, consider that parts of the page (like the CMS content) can also be cached and pushed to the edge more easily than, say, a shipping estimate or personalized product recommendations, so you can have content as part of that initial placeholder flush. We have an e-commerce example that shows this[2].

[1] https://github.com/rauchg/how-is-this-not-illegal/blob/main/...

[2] https://app-router.vercel.app/streaming/edge/product/1

Except my preference for SSR as the default dates as far back as 2014 and is rooted in the laws of physics[1] Downloading an empty shell, downloading code to render a bunch of spinners, to then incur in a bunch of waterfalls of data and more code to the server is not gonna make it.

[1] https://rauchg.com/2014/7-principles-of-rich-web-application...

I believe that was just their demonstration. They're calling it implicit code execution so it's ought to be done transparently to the user for the queries that qualify as requiring code.

Do note that while Astro is a fine choice, your blog has much snappier page transitions with speculative prefetching and pre-rendering, while maintaining an equally good Lighthouse score.

As projects scale this matters more. For example, hard page transitions will accrue the cost of re-initializing the entire application’s scripts for every click.

It's both inline editing and the ability to link arbitrary rendered text to its originating CMS and content flow.

More detail here of how this scales to any content model complexity:

https://twitter.com/rauchg/status/1653800915827310593

Totally, I don't like surprising behaviors either. At the time we made that decision the `CDN-Cache-Control` proposal didn't exist, so it was a tricky spot.

There also really wasn't a UI opportunity in this case (although one thing we thought about was a setting to control it and turn off the Vercel override).

Unless I'm misunderstanding you: it's not about dev or prod. It's that you want Vercel to cache a dynamic page, but not your visitor. That allows you to be in control of the ship: if you purge the CDN, you don't risk a customer having a stale page.

I've seen a lot of customers get burn by sending `max-age` as a way of getting their CDN to cache, not realizing they're inadvertently caching on users' machines. Sometimes it's a seemingly harmless "5 minutes", but that can be damaging enough for rapidly changing pages (imagine breaking news on a homepage).

The gist is (which the support engineer referred to as the internal RFC): instead of stripping `cache-control` `s-maxage` / `stale-while-revalidate` values, we should support Targeted HTTP Cache Control[1] (i.e.: `cdn-cache-control` and `vercel-cache-control`).

Vercel strips them because (1) at the time this RFC didn't exist and (2) most of the time you we found customers don't want to cache on the browser side or proxying CDNs, which makes purging and reasoning about cache staleness very difficult.

Another example there is the default `cache-control: public, max-age=0, must-revalidate`. Without that, browsers have very unintuitive caching behavior for dynamic pages.

Customers want to deploy and see their changes instantly. They want to their customers "go to our blog to see the news" and not have to second guess or fear the latest content will be there.

I appreciate Max's feedback and we'll continue to improve the platform.

[1] https://httpwg.org/specs/rfc9213.html