Data Fetching is no doubt the most important part of React App, because React is data-driven. There are three types of Data Fetching:<ol><li>Static Generation</li><li>Server-side Rendering</li><li>Client-side Rendering</li></ol><figure class="image"><img src="https://images.unsplash.com/photo-1515524738708-327f6b0037a7?ixlib=rb-1.2.1&amp;q=80&amp;fm=jpg&amp;crop=entropy&amp;cs=tinysrgb&amp;w=1080&amp;fit=max&amp;ixid=eyJhcHBfaWQiOjExODA5M30"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@markusspiske?utm_source=unsplash-chrome-extension&amp;utm_medium=referral">Markus Spiske</a></figcaption></figure><h3>Static Generation</h3>Static Generation means the data is fetched at build time. For Next.js versions 9.3 and up, &nbsp;there are two unique functions, getStaticProps and getStaticPaths, which are running at build time to generate &nbsp;data saved in .next/static folder by default. And then those data (HTML and JSON files) will be directly loaded when the page loads, which will certainly increase the performance. &nbsp;The getStaticPaths is used to specify dynamic routes, and define a list of paths that have to be rendered to HTML at build time. &nbsp;We don't use getStaticPaths in DeNiApps, so let's skip this for now, and focus on getStaticProps. &nbsp;To use it, we can simply add the function like below:<pre><code class="language-javascript">export async function getStaticProps() {
 let data = null;
 try {
 const res = await fetch("https://api.tvmaze.com/search/shows?q=nba");
 data = await res.json();
 } catch (err) {
 console.log(err);
 }

 return {
 props: {
 shows: data ? data.map((entry) =&gt; entry.show) : [],
 },
 };
}</code></pre>Then the data retrieved from API will be passed to the page component as props.&nbsp;<h3>Server-side Rendering</h3>Server-side Rendering means the data is fetched on each request before rendering the page. In the React's early day, somewhere in 2015, &nbsp;people called this Universal Rendering:<blockquote>With the help of server side rendering the first rendering is never empty and performance is better.</blockquote>At that time, people used ReduxAsyncConnect, later ReductConnect, and then another popular one named <a target="_blank" rel="noopener noreferrer" href="https://github.com/markdalgleish/redial">redial</a>, and more. But none of them is as easy as NextJS. With NextJS, you only need to add getServerSideProps function into your pages, &nbsp;the function looks the same as getStaticProps. For example:<pre><code class="language-javascript">export async function getServerSideProps() {
 let posts = [];
 try {
 const result = await getPublicPosts();
 posts = result.data.data;
 } catch (error) {
 console.log(error);
 }

 return {
 props: { posts: posts }
 };
}</code></pre><h3>Client-side Rendering</h3>Client-side Rendering means the data is fetched after the page mounted. This is very common in React App when people don't care about Server-side Rendering. Also, in some cases, you may not be able to do Server-side, for example, when the data is only available to the user session, and the user session is saved on the client-side only, like using LocalStorage. In the Object-Oriented way, we can do the data fetching inside, ComponentDidMount, and in a functional way, since React.hook is available after 16.8, we can use useEffect, For example:<pre><code class="language-javascript">async componentDidMount() {
 const ret = await getTags(this.props.accessToken);

 const allTags = ret.data.data;
 const tagsInputOptions = allTags.map((item) =&gt; ({
 value: item.slug,
 text: item.name,
 key: item._id,
 }));

 const newAllOptions = {
 ...this.state.allOptions,
 tags: tagsInputOptions,
 };

 this.setState({ allOptions: newAllOptions });
 }</code></pre>Or:<pre><code class="language-javascript"> useEffect(() =&gt; {
 fetchList();
 setTimeout(() =&gt; {
 setMessage("");
 }, 3000);
 }, []);</code></pre><h3>Final Notes</h3><ul><li>getStaticProps /getServerSideProps has to be used in the page level, not in the component level. &nbsp;So you should use it in any pages (i.e., under pages folder in NextJS.)</li><li>In DEV env, (i.e., npm run dev) the getStaticProps is executing like getServerSideProps.</li><li>getStaticProps is only executed at build time, so it may not work for you, your page is dynamically changed, for example, in DeNiApps, the blog list page have to use getServerSideProps instead of getStaticProps, because we don't want to rebuild the website every time we publish a new post.</li><li>both <a target="_blank" rel="noopener noreferrer" href="https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation">getStaticProps</a>/<a target="_blank" rel="noopener noreferrer" href="https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering">getServerSideProps</a> get context parameter pass in, which includes ‘params’, ‘query’, etc. information, which you may need for the data fetching. Click the links to view details.</li><li>In NextJS 9.2 or older, we can use getInitialProps for server-side rendering. We can still use getInitialProps in NextJS9.3 or newer, especially, if you want to do server-side data fetching in _app.js, because we cannot do getStaticProps or getServerSideProps in _app.js.</li></ul><h3>Bonus Note</h3>The parameter for getInitailProps is different depending on whether we call it in page level or in _app.js, as the example below:<pre><code class="language-javascript">//in pages/home.js
Home.getInitialProps = async ({ req }) =&gt; {
 const md = new MobileDetect(req.headers["user-agent"]);
 const isMobileFromSSR = !!md.mobile();

 return {
 isMobileFromSSR,
 deviceInfo: {
 mobile: md.mobile(),
 tablet: md.tablet(),
 os: md.os(),
 userAgent: md.userAgent(),
 },
 };
};
//in pages/_app.js
deniApp.getInitialProps = async (appContext) =&gt; {
 const agent = appContext.ctx.req
 ? appContext.ctx.req.headers["user-agent"]
 : "";
 const md = new MobileDetect(agent);
 const isMobileFromSSR = !!md.mobile();
 return { isMobileFromSSR };
};</code></pre>As you see in page level, it's context.req, but in _app.js, it's appContex.ctr.req.&nbsp;

In this article, we introduce different ways to do the Data Fetching in a React App, especially with NextJS. You will learn something like, Static generation, Server-side rendering, and Client-side rendering.

Data Fetching In React App with NextJS

Before nextJS 9.4, we can use next.config.js to set up environment variables, i.e., process.env.* which we can use in our application.&nbsp;<figure class="image"><img src="https://images.unsplash.com/photo-1483825366482-1265f6ea9bc9?ixlib=rb-1.2.1&amp;q=80&amp;fm=jpg&amp;crop=entropy&amp;cs=tinysrgb&amp;w=1080&amp;fit=max&amp;ixid=eyJhcHBfaWQiOjExODA5M30"><figcaption>Photo by: <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@veeterzy?utm_source=unsplash-chrome-extension&amp;utm_medium=referral">veeterzy</a></figcaption></figure><h3>With next.config.js</h3>Example of next.config.js like this:<pre><code class="language-javascript">module.exports = {
	// other stuffs
	env: {
		API_HOST:
		process.env.NODE_ENV !== "production"
		? "http://localhost:3030"
		: "http://localhost:5050",
		UER_LC_KEY: "DENIUSER-" + process.env.NODE_ENV,
		SITE_NAME: "DENIAPPS",
	},
};</code></pre>Then, those environment variables are available in Node.js environment and browser. For example: we can use process.env.API_HOST when we fetch the data in Node.js environment, like<pre><code class="language-javascript">export const getStaticProps = async () =&gt; {
 &nbsp;const res = await fetch(process.env.API_HOST/posts')
 &nbsp;const posts: Post[] = await res.json()

 &nbsp;return {
 &nbsp;props: {
 &nbsp;posts,
 &nbsp;},
 &nbsp;}
}</code></pre>Or use process.env.SITE_NAME in a component, like<pre><code class="language-javascript">&lt;Menu.Item header key="menu-0"&gt;
 &lt;Link href="/"&gt;
 &lt;a&gt;
 &nbsp;&lt;Icon name="world" /&gt; {process.env.SITE_NAME}&nbsp;
 &lt;/a&gt;
 &lt;/Link&gt;
&lt;/Menu.Item&gt;;</code></pre>This works fine but has some issues:&nbsp;<ol><li>We have to commit next.config.js to the repository, so if there are some secret environment variables, then it could be accidentally exposed.</li><li>Since there is only one copy of next.config.js, if we deploy the App to a different environment, we may modify this file to have the correct variables setup, which will cause the conflict in the future. Although, we could try to avoid it by checking 'process.env.NODE_ENV', the whole setup would be messy.</li></ol><h3>With .env*</h3>Maybe because this, in Next.js versions 9.4 and up, it comes with built-in support for <a href="&nbsp;https://nextjs.org/docs/basic-features/environment-variables">.env*</a> file.We can now do a lot of things:<ol><li>use .env.*.local to save secret variables, like DB connections, etc. We have '*' in the file name, which means it includes, .env.local, .env.production.local, .env.development.local, and .env.test.local, They are all added to '.gitignore' by default.</li><li>we can have .env (all environments), .env.development (development environment), and .env.production (production environment).</li><li>By default all environment variables loaded through .env (.env.*.local, or .env.*) are only available in the Node.js environment, meaning they won't be exposed to the browser.</li><li>In order to expose a variable to the browser we have to prefix the variable with NEXT_PUBLIC_. For example:</li></ol><pre><code class="language-javascript">NEXT_PUBLIC_SITE_NAME="DENIAPPS"</code></pre><h3>Import Notes</h3><ul><li>When we say “use .env.*.local to save secret variables”, it only means those variable defined in the .local are not shown up in the public repository. If we defined ‘NEXT_PUBLIC_.’ variables in .env.*.local, then they are still visible in the browser.</li><li>.env.local is intended to override the default set, but if we have .env.development.local, then it will override the .env.local, for example: when we run 'npm run dev', it loads,</li></ul><pre><code class="language-plaintext">ready - started server on http://localhost:3000
info - Loaded env from /Projects/next-feathers/next/.env.development.local
info - Loaded env from /Projects/next-feathers/next/.env.local
info - Loaded env from /Projects/next-feathers/next/.env.development
info - Loaded env from /Projects/next-feathers/next/.env
event - compiled successfully</code></pre>Whatever loading first will be used, so the variable defined in .env.development.local overrides the same variable defined in .env.local, which overrides .env.development, which overrides .env.<ul><li>We cannot set PORT in .env file, and we have to pass it via start scripts, like</li></ul><pre><code class="language-plaintext">"start": "next start -p 8080"</code></pre>or<pre><code class="language-plaintext">npm run start -- --port 8082</code></pre><ul><li>Also Next.js document says,</li></ul><blockquote>There is a small difference between test environment, and both development and production that you need to bear in mind: .env.local won't be loaded, as you expect tests to produce the same results for everyone. This way every test execution will use same env defaults across different executions by ignoring your .env.local (which is intended to override the default set).</blockquote><h3>My Opinions</h3>Most of environment variables we defined are probably for client side to use, so by using this new feature, all those variables have to be prefixed with NEXT_PUBLIC_., which is a bit ignoring. I would suggest to do the opposite, which is using NEXT_PRIVATE_. prefix for variables ONLY available to Node.js environment.

Before nextJS 9.4, we could use next.config.js to set up environment variables, i.e., process.env.* which we can use in our application. In nextJS version 9.4 and up, we could use .env* files. At first glance, they make this complicated, but they have been given a purpose. In the article, we will go over this, and see how we benefit from this new feature.

Set Environment Variables in Next.JS

<a target="_blank" rel="noopener noreferrer" href="https://github.com/deniapps/nextfeathers">NextFeathers</a> uses JSON web token (JWT) for authentication when calling the Restful API implemented by FeathersJS. &nbsp; The JWT token was simply saved in the browser's localStorage and removed when the user is logged out. Many people said this is very bad because the hacker could run Javascript via what so-called XSS on your website, and read the data from localStorage. Personally, I kinda against this because it's unlikely happened, and as I know that is how <a target="_blank" rel="noopener noreferrer" href="https://github.com/aws-amplify/amplify-js/issues/3224">AWS-amplify </a>works by default. But there is indeed a risk, so I would like to fix it.<figure class="image"><img src="https://images.unsplash.com/photo-1562663626-db7642010d11?ixlib=rb-1.2.1&amp;q=80&amp;fm=jpg&amp;crop=entropy&amp;cs=tinysrgb&amp;w=1080&amp;fit=max&amp;ixid=eyJhcHBfaWQiOjE1NDAxMH0"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@dfartek?utm_source=DNX&amp;utm_medium=referral">David Fartek</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Saving JWT to HttpOnly Cookie sounds like a solution, but there is an issue that I have &nbsp;“Next' and ”Feathers" on different domains (i.e. different ports,) and the cookie can only be sent with requests made to the same domain inside a <code>Cookie</code> HTTP header. That means, we set the httpOnly cookie on deniapps.com, which cannot be sent to api.deniapps.com, so we are not able to pass the JWT token for authentication. To fix this, we have to use a middleware called Proxy. So the API request will be sent to the same domain, for example, https://deniapps.com/api/proxy/post, and then the Proxy will pass the request to the real API at https://api.deniapps.com/post.&nbsp;The overall workflow is like below:<ol><li>User logs in at https://deniapps.com/api/proxy/authentication.</li><li>The proxy transfers the request URL to the real API endpoint, for example, http://localhost:3030/authentication&nbsp;</li><li>Before the proxy sends the response back to the client, it saves the accessToken to the httpOnly cookie and sends only the user's info (like username, email, etc.) back to the client.</li><li>The client saves the user's info into the user context used by other page components.</li><li>When the client makes any private API call, it calls the proxy endpoint, like https://deniapps.com/api/proxy/posts.</li><li>The proxy reads the cookie for JWT, which is set to the “Authorization” header before calling the real URL endpoint.</li><li>When the client receives the response passed by the proxy, it checks the HTTP status. If it's 401, then log out the user, otherwise, use response data to render the page.</li></ol>The main part is pages/proxy/[…path].js, which I modified from the one in <a target="_blank" rel="noopener noreferrer" href="https://maxschmitt.me/posts/next-js-http-only-cookie-auth-tokens/">Max's post</a>. (Thank you! Max)<pre><code class="language-javascript" id="j1zy23qDh">import httpProxy from "http-proxy";
import Cookies from "cookies";
import url from "url";

const API_URL = process.env.API_HOST;

const proxy = httpProxy.createProxyServer();

export const config = {
 api: {
 bodyParser: false,
 },
};

export default (req, res) =&gt; {
 return new Promise((resolve, reject) =&gt; {
 const pathname = url.parse(req.url).pathname;
 const isLogin = pathname === "/api/proxy/authentication";

 const cookies = new Cookies(req, res);
 const authToken = cookies.get("auth-token");

 // Rewrite URL, strip out leading '/api'
 // '/api/proxy/*' becomes '${API_URL}/*'
 req.url = req.url.replace(/^\/api\/proxy/, "");

 // Don't forward cookies to API
 req.headers.cookie = "";

 // Set auth-token header from cookie
 if (authToken) {
 req.headers["Authorization"] = authToken;
 }

 proxy
 .once("proxyRes", (proxyRes, req, res) =&gt; {
 if (isLogin) {
 let responseBody = "";
 proxyRes.on("data", (chunk) =&gt; {
 responseBody += chunk;
 });

 proxyRes.on("end", () =&gt; {
 try {
 const { accessToken, user } = JSON.parse(responseBody);
 const cookies = new Cookies(req, res);
 cookies.set("auth-token", accessToken, {
 httpOnly: true,
 sameSite: "lax", // CSRF protection
 });

 res.status(200).json({ user });
 resolve();
 } catch (err) {
 reject(err);
 }
 });
 } else {
 resolve();
 }
 })
 .once("error", reject)
 .web(req, res, {
 target: API_URL,
 autoRewrite: false,
 selfHandleResponse: isLogin,
 });
 });
};
</code></pre>I also created a local API to check if the user is logged in named “check-login.js” as below:<pre><code class="language-javascript" id="O5OpdguAb">/**
 * pages/api/check-login.js
 *
 * A API endpoint for checking if the user is logged in.
 */
import { isExpired } from "helpers/common";

export default (req, res) =&gt; {
 const Cookies = require("cookies");
 const cookies = new Cookies(req, res);
 const authToken = cookies.get("auth-token") || "";

 const loggedIn = !isExpired(authToken);

 res.status(200).json({
 loggedIn,
 });
};</code></pre>I checked user is logged in in the _app.js when the componentDidMount, so basically every time a page is hard loaded, it will check if the user is logged in, if so, user info is shown on the header, otherwise, the “Login” button is shown instead.<pre><code class="language-plaintext" id="DcTiwQgBJ">/**
 * pages/_app.js
 */ 
 componentDidMount = async () =&gt; {
 const deniUser = localStorage.getItem(NEXT_PUBLIC_USER_LC_KEY);

 if (deniUser) {
 const userStatus = await axios
 .get("/api/check-login")
 .then((response) =&gt; response.data);
 if (userStatus.loggedIn) {
 const deniUserObj = JSON.parse(deniUser);
 this.setState({
 user: deniUserObj.firstName,
 });
 }
 }
 this.setState({
 isReady: true,
 });

 };</code></pre><h3>Note</h3>Initially, I used https://api.deniapps.com in the production, but go the following error:<pre><code class="language-plaintext" id="kEVvo-6By">SyntaxError: Unexpected token in JSON at position 0</code></pre>I think it's related to HTTP. To use HTTPS as a proxy target, we need to use “SSL” options with key/cert defined. But since, I have an API server running on the same server with a different port, so I could just change it to http://localhost:5050.&nbsp;Also, here I don't set cookie expiration, so it expires at the end of the session (the could mean a different thing for different browsers.)&nbsp;The last thing, you may take a look at how I implement the log out at &nbsp;<a target="_blank" rel="noopener noreferrer" href="https://github.com/deniapps/nextfeathers">NextFeathers</a>. And check out how to <a target="_blank" rel="noopener noreferrer" href="https://deniapps.com/blog/jwt-token-auto-renew-auto-logout">renew the access token</a> if needed.

NextFeathers uses JSON web token (JWT) for authentication when calling the Restful API implemented by FeathersJS.   The JWT token was simply saved in the browser's localStorage and removed when the user is logged out. Many people said this is very bad because the hacker could run Javascript via what so-called XSS on your website, and read the data from localStorage. Personally, I kinda against this because it's unlikely happened, and as I know that is how AWS-amplify works by default. But there is indeed a risk, so I would like to fix it.

All Posts In Nextjs