Skip to content

Conversation

conico974
Copy link
Contributor

This PR add basic support for PPR.

This is the PPR built into next standalone, this mean that nothing can be served from the CDN (except the prefetched rsc).

The html are served from the server every time

Copy link

pkg-pr-new bot commented Oct 10, 2024

Open in Stackblitz

pnpm add https://pkg.pr.new/@opennextjs/aws@542

commit: cf0b020

Copy link
Contributor

@khuezy khuezy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Is ppr that easy to enable? Even if it's just a basic version.

@conico974
Copy link
Contributor Author

Yeah we had already everything in place, so it was very easy (I thought it would be a little harder though, but not by much)

The thing is, it's probably not worth it in a lot of cases. The S3 latency could make it totally worthless depending on what's prerendered. And you could end up paying a lot more, 1 S3 GET for every request instead of a few ms of a running lambda

@khuezy
Copy link
Contributor

khuezy commented Oct 10, 2024

Hmm shouldn't those static assets be generated w/ cache-control headers, something like s-maxage=1yearish, immutable. I would assume those static assets hit S3 only once and then stored at the CDN.

@conico974
Copy link
Contributor Author

Hmm shouldn't those static assets be generated w/ cache-control headers, something like s-maxage=1yearish, immutable. I would assume those static assets hit S3 only once and then stored at the CDN.

We could add a cache layer between S3 and those assets, but that's just moving the problem. It still needs to be accessed by the server function itself, it cannot be served directly to the user.

It is streamed and no CDN can cache only a part of the stream and request the rest from the origin ( At least for now )

Basically it does this:

User request PPR route => Server Function Request Prerendered Part from S3 => Server starts the stream with the prerendered part => It appends SSR part to the existing stream

That's why for me real PPR needs to be done at the CDN level, in workers you could cache the prerendered part directly in the CDN and start the stream right away

@khuezy
Copy link
Contributor

khuezy commented Oct 10, 2024

I must not fully understand the PPR architecture. I assumed the static shell parts are determined at build time. Then when the client makes a request, it streams back the shell that points to the static asset, then continues w/ the suspense boundary stuff.

I haven't dived into the source code to figure this out yet though.

@conico974
Copy link
Contributor Author

That's basically that.
The only thing is that it does that in a single stream, and they don't provide us with only the resume endpoint (unless using minimal mode).
And to add to that, the first html shell is not always fully generated at build time, sometimes it is generated at runtime from some RSC.

@conico974 conico974 merged commit 178ab2b into opennextjs:main Oct 15, 2024
3 checks passed
@github-actions github-actions bot mentioned this pull request Oct 15, 2024
@conico974 conico974 mentioned this pull request Oct 16, 2024
@conico974 conico974 deleted the feat/basic-ppr branch October 29, 2024 10:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants