score:4

despite we ended up leaving next.js for this and other reasons that made us decide next.js was not the best option for our use case, we kind of mitigated this problem as follows while be sticked to it, i hope it makes sense to anyone. also, by now maybe next.js provides a better way to do this so i would read the next.js docs before using my approach. final note: i don't have access to the code anymore since i change to a different company so maybe there are some points that won't be 100% as we made it.

there is goes:

  1. we created a module that was responsible to request the config file and keep the results in a variable. at the moment of importing this module, we ensure that the variable is not already present in window.__next_data__. if it is, we recover it, if it's not, we request it to the remote server (this will be helpful in the clint side rendering).
  2. we created a server.js file as described by next.js docs. in this file we make the call to get the config file and store it in memory.
  3. in the body of the function passed to createserver we add the config file into the req object to make it accesible to the app in the getinitialprops functions server side.
  4. we made sure that the getinitialprops using the config file returns it, so that it will be passed to the components as props and also serialized by next.js and made available to the client in the __next_data__ global javascript variable.
  5. given that the config ended up in the __next_data__ variable in the server, using the trick described in the step 1 makes the app not request the config for a second time.

score:5

you are correct in that anything in getinitialprops in _app.js or _document.js will be run on every server request. once you get your config, you can pass it down to the components in pages as props. from there, i think you have two choices:

  1. now that the app is bootstrapped, run the rest of the app as a spa client-side. this would prevent any future ssr from happening. obviously, you lose the benefits of ssr and the initial page load is likely longer, but then it would be snappy afterwards.
  2. after getting the config in _app.js, send it as a cookie (assuming it's not too big to be a cookie?). on future requests to the server, the cookie will be sent automatically and you would check the cookie first - if it doesn't exist, get the config. if it does exist, skip that more expensive bootstrapping because the app is bootstrapped.

so i think it really depends on whether you want a single page application bootstrapped on the server but then entirely client side after that (option 1) or server side rendering per page while minimizing expensive bootstrapping (option 2).

nothing prevents you from sending multiple cookies from the server if that makes sense for your app and bootstrapping. and remember not to make it a http-only cookie because you'll want to read that cookie client side - after all, that's what you're looking for - the client side configuration generated on the server.


Related Query

More Query from same tag