Next.js: Export `getInitialProps` data to json file to avoid recalling API

[jepser]

One of the cool features of Gatsby is to "store" the payload that comes from the data sources into a "locally" internal .json files, which prevents after build to get the data from that files instead of an API call to the real source.

next.js during the build, keeps the reference to the real API, in case used, ex.

childLanding.getInitialProps = async ({query, req}) => {
  const {
    id
  } = query

  let thumbnails = []

  const pageRequest = await fetch(`https://superduperapi.com/v1/landing/${id}`)
  const data = await pageRequest.json()

  return {
    data: data
  }
}

Then when there is a link one exported page to the other one using Link the component runs getInitialProps again, doing the SSR no sense.

Is there a way to achieve or manage this conditional.

[krunalatkaplan]

+1. We can serve exported JSON from static file server / S3 instead of burning API server.

[pddigital]

NEXT already stores the request as JSON in the page's HTML markup when it's SSR rendered.
Also, I would in your case use a middleman API server to cache the requests in Redis. That's more efficient than JSON files...

[krunalatkaplan]

Middleman API server + Redis lookup x (N APIs) Vs Single S3 object served from cloudfront. What do you think is more efficient?

I believe static site generator are useful when you know that you underneath data/content does not change often and you can regenerate your site when they change instead of repetitive API call / cache look up / database call.

[pddigital]

Ill have to try that, but I already have an API server... to normalize the data and do other operations. Furthermore, I don't use Amazon! So Redis is a great option for me.

[jepser]

@pddigital is not only because of Amazon, but you could set your site in Surge or Netifly easily for example. So you said it already saves the data in .json files, for what is that if it does the recall to the API on load?

[pddigital]

Gotcha, caching JSON files for the build process... That's probably a good feature if you're doing a basic website where cache devalidation is simple or not a huge concern.

I was thinking client-side... the JSON is rendered on the server and made available to the client. Pretty much any SSR example, including manual SSR, will encode the JSON on an object (usually on the window object, Next has it's own __NEXT-DATA_ object). The data isn't just used for rendering page content, it can be used during runtime as well. Because the client isn't doing the fetching, the JSON has to live somewhere in the rendered page, otherwise it won't be usable beyond the first render.

[krunalatkaplan]

+1 Paul. The prominant usecase is headless cms, where it may be needed to make multiple API call in getInitialProps, and it will be unnecessory to put pressure(by keep invoking same API call from client) on CMS, even though there is no change in content.

[jepser]

So any recommendation on this? A could work on a webpack plugin, any requirements or ideas to narrow the scope?

[safeimuslim]

How to implement await , when i dispatch to redux ?

[tomsseisums]

I feel like this is related to: https://github.com/zeit/next.js/issues/4999

[timneutkens]

Inlining the data is already possible using babel-plugin-preval, similar to https://github.com/zeit/next.js/blob/canary/examples/with-babel-macros/pages/index.js#L4-L7

[krunalatkaplan]

@timneutkens Do you recommend using preval.macro instead of getInitialProps to get the data?

[gavinsharp]

Inlining the data is already possible using babel-plugin-preval, similar to https://github.com/zeit/next.js/blob/canary/examples/with-babel-macros/pages/index.js#L4-L7

This is not a great solution - doing meaningful work with preval is annoying, because you can't write async code, and the prevaled code doesn't get transpiled. A solution to https://github.com/zeit/next.js/issues/4810 would be much appreciated!

[Timer]

See RFC fixing this: #9524