Netlify On-demand Builders - would they help with the Netlify Adapter?

[benaltair]

Suggestion

Recently, Netlify released a blog post detailing On-demand Builders, a new feature that helps with SSR JS frameworks. It's in early access, but from my preliminary reading it seems it might help with Kit's Netlify adapter.

Read the docs here.

Ways Forward

Perhaps On-demand Builders isn't compatible with Kit's current methodology, so this issue could be closed then. My hope was that in case it is compatible and helpful, soon it might be a good time to begin implementing it, while the project is young. Or maybe that would cause additional pain to have two pre-release projects interacting. Since it's only the adapter that should need to be modified, perhaps it's lower risk though.

I'm curious on any thoughts that come up. Feel free to close if it's not compatible with the project's stack or aims.

[swyxio]

it is very early days for ODB's and imo Netlify needs to put out more documentation before we can assess if its ready for adoption. i think the ideas are inherently compatible, but probably need to introduce something like prerender: onDemand instead of a simple true or false boolean.

perhaps someone on @jlengstorf's team can help with implementing on demand builders?

[ascorbic]

Hey! I'm happy to help out with this. I see a few possibilities with the API, in additon to the one suggested by @sw-yx.

First, there are the restrictions that need to be considered. ODBs are cached based on the URL, but without the query string. They only work for GET requests. For this reason they aren't suitable if you expect to generate different content based on query strings or headers. The cache lifetime is also not something you should rely on: they can be evicted for any reason, and are always evicted when a new build is done. For this reason they shouldn't be used for anything where the underlying data source may change. What they are great for though is long tail content, or other content that can change arbitrarily based on the URL.

One approach would be to apply it to all pages that are not pre-rendered, and leave regular functions for endpoints only. This wouldn't work if you expect pages to be updated between deploys, or if you expect to deliver different content based on anything except the URL.
Alternatively there's @sw-yx 's approach of having a flag. My main concern about that is the detail: prerender = onDemand sounds like a contradiction! Maybe another flag persist = true, and don't set prerender. This also fits with the "distributed persistent rendering" name for the generic approach.

The main implementaiton issue is that ODBs are implemented by wrapping the render function, so it iether needs a separate entry point than other functions, or the wrapper needs some way of identifying an incoming request as on-demand so that it can pass it over to the ODB handler. We'd either need a way of seeing this in the request, or in the response generated by the app.

[swyxio]

i just dislike filling up the sveltekit api with a bunch of boolean flags and then having to account for the combinatorial explosion of possibilities among them.

[jlengstorf]

what about something like prerender: deferred or prerender: serverless? it sounds a little less contradictory and avoids introducing new flags, while still lining up with the DPR reasoning (the same process as build-time prerendering is used, but the rendering is deferred until the first request)

[swyxio]

yes, this would also work :)

bottomline is i think sveltekit users are keen on trying out the ODB concept, they just need the kickstart of how to set this up/build this into the sveltekit netlify adapter

[Xenonym]

Been looking into this for a bit. I think adding ODB support into the Netlify adapter might be challenging:

Builders are created by wrapping a builder() function around an existing handler. This means that whether a function is an ODB or a regular Netlify function is fixed at build time; there's no way to dynamically return a regular or ODB response depending on an incoming request. Netlify staff has also confirmed this is intended.

This means that we would need two handlers, one for regular routes, and one for routes that can be ODB-ed. We would then need to generate an appropriate _redirects file that redirects every SvelteKit route to the regular or ODB handler based on some criteria (e.g. page routes can be all ODB-ed). This is also the approach used by Netlify's own build plugins for NextJS and Gatsby.

The main issue would be in generating the _redirects file. The adapter would need to be able to access a list of all routes, as well as which are endpoints and which are pages, and append the necessary rules for redirects. Is this an ability that is available to SvelteKit adapters at the moment?

[ascorbic]

Yes, @Xenonym that's a good summary. I'm on te team that maintains build plugins and other framework integrations and am happy to help with this in any way I can. The approach of two functions and redirects is currently the only way to do it, though we are actively working on the next iteration of the API and there will be a new release very soon (i.e. the next couple of weeks).

[Xenonym]

That's great news @ascorbic! Look forward to the new changes, hopefully they might help :)

[benaltair]

@Xenonym I'm not entirely sure if this applies, but from what I understand in your comment, have you looked into dynamic redirects in Netlify? I wonder if this would apply here. Something with placeholders or :splat for instance could possibly pass the path data to a function as a query parameter or similar. Not familiar enough to know if that's a robust approach.

[Xenonym]

@benaltair thanks for the suggestion! Transforming query parameters to path segments is actually a documented workaround for ODBs when you don't control the shape of the request (e.g. your ODB receives requests from an external API). Unfortunately, that doesn't quite help us here, since there's nothing in the path structure that indicates if it is a page (ODBed) or an endpoint (rendered as normal).

---

P.S. You could make this a viable strategy for your own app by having a convention for routes that should be ODBed (e.g. all routes that match /odb/:splat could be ODBed), but this would not be something that we can enforce on the SvelteKit level.

[swyxio]

checking in on this again - @ascorbic i have a use case for this if you are keen to implement it in the sveltekit adapter swyxio/swyxkit#10