Initial Static Generation at runtime / improve Docker compat #17111
mAAdhaTTah
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Feature request
Is your feature request related to a problem? Please describe.
We're hosting our Next.js app on Docker and have a couple of env vars that are used in the
<head>of the page. Because of this particular combo, we can't take advantage of static generation at all, because we can't inject these env vars at buildtime (we want to build the Docker container once and ship it into multiple environments with different env vars, so they can only be provided at runtime) and they don't "work" at runtime (the static HTML has already been generated with the env vars missing at buildtime).In general, there's an underlying issue pairing Docker with Next.js + runtime variables, as seen in some of these discussions:
Most of these suggestions use build args to solve the problem, but this loses one of the main benefits of Docker: build once, deploy anywhere. If any of the env variables are related to the environment you're deploying to (API URLs are probs the most common), you can't inject the env vars at build time.
Describe the solution you'd like
At a high level, improving the interop with Docker is my goal. Next.js already has runtime configuration, and it would be excellent to take advantage of those while keeping some of the benefits of static generation. My workaround (described below) essentially replicates this, but I'm not 100% sure this is a "blessed" approach–it feels rather hacky and am definitely concerned upcoming versions of Next.js will break it.
The specific suggestion here is to explicitly enable deferring static generation to runtime and thus statically generate everything when the env vars are available. Then the
publicRuntimeConfigbecomes available again in statically generated pages.Describe alternatives you've considered
I'm currently taking a workaround (described here) to fake this feature, delaying static generation until the app starts up by providing an empty array of paths during the initial build & populating it with the actual value at the initial request. I also had to opt-out of static generation for pages with no data fetching functions by adding a dummy
getInitialPropsin_app(this in particular seems a bit odd–why are pages with no data fetching requirements not statically generated the same way as those withgSPrequirements? Although I think without this behavior, my hack wouldn't work).Additional context
I had posted an initial question here, which the suggestion was basically "use
gSSP", which is also a possible solution but it would be nice to not regenerate the page from scratch every time when it's basically static.I do know there's a lot of work still being done around static generation so if this is something in progress already, my apologies.
Beta Was this translation helpful? Give feedback.
All reactions