12
Building an App Based on the Next.js Toolkit, Authentication, SWR, GraphQL, and Deployment
Throughout our journey in this book, we have learned new skills, methodologies, and better ways of thinking. This chapter is the culmination of our efforts, so let’s move forward, as it is now time for us to put everything we have learned together as we seek to develop an exciting application that features an up-to-date modern tech stack. This chapter will allow us to progress from concept to the deployment of a Next.js application that has implementations for authentication, stale-while-revalidate (SWR), GraphQL, and deployment.
We will start with a quick introduction to REST APIs, which will be a fantastic refresher if you are already familiar with them, or a great introduction if it’s your first time learning about this essential methodology. Then, we shall move on to figuring out how best to plan the architecture for an application, where we will go into how authentication works. This will be followed up by how effective SWR is and why it’s worth using, as it’s a very useful aspect that can enhance the performance of our applications. Next, we will learn about GraphQL and how it compares with traditional REST APIs. Then, we will end with deployment, which is where we finally publish our local development build online so that the whole world can use it.
In the sections that follow, we will talk about the ideas behind business logic and how the code we write has significant importance not just for the way our application runs but also for how it can reflect positively or negatively on our team and company depending on how well it is written. Moving on, we will go through creating the presentation layer, which is essential to the user interface and user experience. Testing is going to be the next major feature that we touch on, as it’s highly recommended that production-ready applications have a robust testing suite set up to guarantee that it is stable and in a state that is ready to be published as a minimum viable product (MVP).
With those features completed, we will finish off by learning how to deploy our application so that the public can access it. In the last sections, we will create a Git repository with a README file.
In terms of topics, the following will be the themes that we will be focusing on in the upcoming sections:
- Quick introduction to REST APIs
- Planning the application architecture including authentication, SWR, GraphQL, and deployment
- Building the business logic
- Building the presentation layer
- Implementing testing
- Creating a Git repository with README documentation
- Deploying the application for public access
Technical requirements
On your machine, confirm that https://nodejs.org/en is up to date and that the JavaScript Node package for Next.js is set up and operational. You can use whatever package manager you want, be it npm, yarn, or pnpm. Just make sure that you use the appropriate commands when doing the installation. For simplicity’s sake, we will be using npm. Work on your project with your preferred integrated development environment (IDE) and command-line interface (CLI) tool. You will also need to have an account on https://vercel.com/ for the deployment section when we build our app. For the authentication section, we will use GitHub and Google, so in the unlikely event that you don’t have accounts for both of these services already, create one now. GitHub is also required for the version control section, so it’s essential for you to have an account.
The package for Next.js can be found at https://nextjs.org/.
The project and code base can be found online at https://github.com/PacktPublishing/React-Interview-Guide/tree/main/Chapter12/coffee-restaurant.
To begin, let’s first talk about REST APIs to understand their core concepts.
Quick introduction to REST APIs
A Representational State Transfer Application Programming Interface (REST API) is a particular technology that has established itself as the cornerstone of contemporary web development. By using REST APIs within JavaScript and React applications, developers can develop robust and dynamic web apps that can communicate with other platforms and information sources. Developers can transfer data between the server and client using the REST API without worrying about the architecture of the underlying apps. In simple terms, the REST API standardizes communication protocols, which simplifies development. With the correct tools and skills, REST APIs can totally alter the way web developers work.
We can easily understand the core methodology and concept of a REST API by using a restaurant as an example. This is considered to be a popular way to describe how the process works. For example, let’s say that a user has a restaurant application. Basically, the user requests some data for their menu page, which is equivalent to a user in a restaurant asking a waiter for some food. In this case, the waiter who is taking the food request is the same as the API taking the request to display the menu. The waiter then goes to the kitchen to get the food, which is equivalent to the API getting the application.
So, let’s imagine that the application has a list of food on the menu. A customer takes a look at the menu and then gives their order to a waiter. The waiter goes to the kitchen with the customer’s order and waits for the meal to be completed. When the food is ready, the kitchen staff give the food to the waiter, who then responds by returning to the customer with the food they requested. In a real-world situation, the customer now has a meal to eat. If we imagine this as a website, then a page has now loaded with a table that shows food from the menu inside it. This information was fetched via the API to the backend server application, which returned it.
This example is perfectly illustrated in Figure 12.1.
Figure 12.1: Describing a REST API
Let’s now learn how we can manage our APIs using various tools. This is another important skill for developers to have.
What tools can we use for testing our APIs?
When doing API development, it is normal for a developer to use an API tool for managing, testing, and interacting with the API. Some of the most popular API development tools for JavaScript development can be seen in Table 12.1:
Table 12.1: Popular JavaScript REST API tools
With these tools, we can thoroughly test our REST APIs and it is even possible to use this as a basis for creating the documentation. There is something that we need to be aware of though when building APIs, and that is cross-origin resource sharing (CORS). CORS is basically an application integration method. CORS specifies a method for client web applications loaded in a single domain to communicate with assets located in another domain. So, essentially, if we do not specify or allow CORS access in our APIs, then we will be blocked from accessing them unless they are on the same server.
For example, we could have an API hosted online on a website, and let’s say that we have a React application that is online on a different server somewhere. If our API is not set up for CORS, then our React application can’t connect to it to retrieve any data, and we will just get a CORS error in our browser console, as shown in the following figure:
Figure 12.2: A CORS error web browser console message
It’s time to move on to learning about REST APIs in more detail now that we have a better understanding of how they are set up. So, let’s see what features are on offer.
Which features are available in a REST API?
A REST API is a strong tool that gives developers access to a wide range of functions. The REST API’s excellent security system is one of its most important characteristics. It guarantees that any malicious attacks won’t be made on the data given over the API. Additionally, the REST API’s capacity to scale is another crucial aspect, which implies that it is a great option for apps with heavy traffic because it can manage a lot of queries. Another remarkable quality of REST APIs is their flexibility, which lets developers use any architecture or technology of their choosing. REST APIs are an excellent tool for developers who wish to create dependable and durable apps thanks to all these features taken together.
A REST API is capable of requesting and responding to requests, but what does that mean? Let’s find out.
What is the difference between requests and responses when making requests to a REST API?
Understanding how HTTP requests and responses operate is essential if you want to create a web application that connects to a REST API. Data is sent from a client to a server using HTTP requests, and it is sent back from the server to the client using HTTP responses. REST APIs interact between clients and servers using GET, POST, PUT, and DELETE standard HTTP protocols. We can build web apps that easily interface with REST APIs by designing them with greater effectiveness and efficiency by knowing how these requests and responses operate. There are other HTTP protocols available, but the standard ones are the most common. Now, let’s understand the difference between these HTTP protocols.
What is a GET request?
A GET request is a method that is used to obtain data from the server. It is a read-only procedure so there is no negative impact on the server. GET requests do not cause the data or the server to change its state.
What is a POST request?
A POST request is used to transmit information to the server in order to establish new data. It is not immutable, which means that submitting the same POST request many times might get different results. POST requests generally return the URL or an instance of the newly created resource.
What is a PUT request?
A PUT request can be utilized to add new information to preexisting server data. It is capable of change, so you can send the same PUT request to get different results. Based on the way it’s done, if the data does not exist, the server could create it.
What is a DELETE request?
The DELETE request is used to remove data from the server. It is also immutable, which means that sending the same DELETE request multiple times has the same outcome. Following the deletion of data, the server normally provides a status indicating whether the action was successful or unsuccessful.
We can see an example REST API application in this code example here:
const express = require('express');
const cors = require('cors');
const path = require('path');
require('dotenv').config();
const app = express();
app.use(cors());
app.use(express.urlencoded({ extended: false }));
app.use(express.json());
app.use('/static', express.static(path.join
(__dirname + '/public')));
app.get('/api', (req, res) => {
res.json({ msg: 'API Route' });
});
app.post('/post/:data', (req, res) => {
const data = req.params.data;
console.log(data);
res.json({ msg: `Data logged ${data}` });
});
const port = process.env.PORT || 8080;
app.listen(port, () =>
console.log(`Server running on port ${port},
http://localhost:${port}`)
); In this example, we have a static route, which is used for serving files such as images, CSS, and JavaScript, for example, so long as they are in a public folder in our app. We have a GET route for the API, which just returns a JSON object. Lastly, we have a POST route, which logs to the console and returns a JSON object of whatever text a user sends as a POST request, as in this example: http://localhost:8080/post/helloworld.
HTTP protocols are just one aspect of a REST API. It is also important to have good authentication set up. Continue reading to see why this is the case.
Why is authentication important when using a REST API?
Using a REST API requires authentication to ensure that private data is kept secure. Authentication requires confirming the user’s identity before giving access to API capabilities. This helps to avoid unauthorized data access or usage, which might endanger users. When communicating with an API, you’ll probably utilize a variety of authentication mechanisms, including token-based authentication and OAuth. These methods guarantee that only authorized users have access to the API and are allowed to send requests or get data. Understanding authentication while interacting with a REST API can potentially assist us in building a more secure and efficient solution. It is possible to understand authentication flow if we see it in a diagram such as this one:
Figure 12.3: The REST API authentication flow
Another aspect worth discussing is error handling because it’s crucial that we check for mistakes, which is very important when authentication and user details are involved. Let’s discover how having effective error handling can make our application more trustworthy.
How can we use error handling when integrating with a REST API?
Connecting with a REST API is occasionally difficult, especially when confronted with errors. However, having a robust error-handling plan in place could spare us time and hassle in the long term. One useful strategy is to specify error codes and messages that our application can recognize and respond to. Furthermore, installing automatic retries and monitoring systems can assist in identifying and addressing issues more rapidly. Another important topic is dealing with data validation mistakes, as API inputs must be thoroughly scrutinized before being utilized in our application. We can ensure easy integration with a REST API and deliver an improved user experience for our clients by being proactive and comprehensive in our approach to error management.
The last topic we’ll cover in this section is GraphQL. So, let’s now see how GraphQL compares with a traditional REST API.
What is the difference between a REST API and GraphQL?
REST and GraphQL are two techniques for the creation and operation of web service APIs; however, they differ in numerous ways. GraphQL tends to be more flexible because you can request only the data you need and not all at once as with REST APIs. This is great because it means fewer data transfer requests on the network. Another area GraphQL excels in is versioning history because it is not reliant on versions, which is the case with REST APIs, requiring more manual hands-on work. Despite this, they both have pros and cons over each other and, when comparing the two, we can see how they offer us different advantages and disadvantages.
Fetching data
The end user often uses a REST API to access resources through preset endpoints, where each endpoint is associated with a single resource or a group of related resources. The client makes HTTP requests to these endpoints in order to get or modify data. When using GraphQL, a client sends queries or mutations to a single endpoint, indicating the data it requires or the modifications it wants to make. In comparison to REST API, this allows the client to only retrieve the data they actually need, eliminating the need for requesting more data than required or too little data.
Caching data
To improve efficiency and lessen server load, REST APIs can make use of ETags and cache-control headers, two common HTTP caching methods. In contrast, because of GraphQL’s flexible query form, caching is more difficult. The usage of unique caching techniques offered by GraphQL client-side libraries such as Apollo Client or application-level caching is frequently required by clients.
Documentation
Within REST APIs, documentation is frequently given separately, and it is the responsibility of the programmers to keep it up to date. If not kept up with, this can result in contradictions and inaccurate data. On the other hand, since GraphQL includes built-in introspection, users can dynamically learn about the different kinds and features of the API. Engineers can explore and comprehend the API more easily, frequently using tools such as GraphiQL.
To end this section, we are going to take a look at some code examples of fetching some data using REST and GraphQL so it becomes clear how the two methods differ from each other.
How do we fetch data using REST APIs and GraphQL?
We will take a look at code examples for fetching data using REST and GraphQL, starting with REST APIs. In these examples, we will use authors and posts.
How do we fetch data using REST APIs?
The first step is to get a post that has an ID of 1:
GET /posts/1
This is what a potential sample response might look like:
{
"id": 1,
"title": "Hello World",
"content": "Welcome to my first blog.",
"authorId": 64
} When using a REST API for data retrieval, requests return all of the information in the data object. It is not possible to request, let’s say, only the id and title information. We would have to write business logic in JavaScript to filter the object so that we only get the data we want to use in our application.
So, if we wanted to get details for the author, then we would have to send a second GET request:
GET /authors/64
Now, we’ll have the author’s info:
{
"id": 64,
"name": "Jack Thomas",
"email": "jackthomas@gmail.com"
} So, now that we have understood the basic concept of fetching data using REST APIs, let’s see how we can do the same but this time using GraphQL.
How do we fetch data using GraphQL?
When we use GraphQL, we first need to create a schema for our API, as shown in the following example:
type Post {
id: ID!
title: String!
content: String!
author: Author!
}
type Author {
id: ID!
name: String!
email: String!
}
type Query {
post(id: ID!): Post
} Then, we need to write a GraphQL query to get the author and a post:
query {
post(id: 1) {
id
title
content
author {
id
name
email
}
}
} The response will look something like this:
{
"data": {
"post": {
"id": "1",
"title": "Hello World",
"content": " Welcome to my first blog.",
"author": {
"id": "64",
"name": " Jack Thomas",
"email": " jackthomas@gmail.com"
}
}
}
} GraphQL allows us to retrieve the necessary data with a single request by defining the fields we desire.
Ultimately, deciding between a REST API and GraphQL boils down to our specific use cases and requirements. Both have distinct characteristics and abilities that can help us optimize the development process while creating web or mobile apps. However, as with many technological issues, it is critical for us to consider all of our alternatives before settling on the best method. We can safely use a REST API or GraphQL within our React applications to obtain the desired outcome if we can grasp their common qualities and special benefits. Whatever technology we employ, the objective should always be to provide safe, scalable, and effective solutions for those who use the app.
Now that we have completed this introductory refresher section, let’s take the next step and create the foundation for building our app as we learn about the planning required for the architecture.
Planning the application architecture including authentication, SWR, GraphQL, and deployment
In today’s fiercely competitive marketplace, it is imperative to possess the know-how of designing, developing, and deploying an application architecture that is efficient, secure, and meets user needs. However, with the advent of evolving technologies such as Next.js, authentication methods transitioning from traditional OAuth 2.0 to SWR, and GraphQL gaining popularity, planning our application architecture might seem like a daunting task.
In this section, we will get valuable insights to assist us in organizing our application for success, from selecting the appropriate technologies to incorporating user experience design elements. By the end of this section, we will have a roadmap to guide us through building our next project, with clear steps to follow through to completion.
Our next topic focuses on serverless frameworks. So, let’s read on and see why they are a brilliant choice for building modern apps.
Why are serverless frameworks such as Next.js a brilliant choice for building modern applications?
New frameworks and architectures are developed as digital technology advances to better the effectiveness of building web applications. Next.js is one of these architectures because of its speed and flexibility. Next.js apps have a distinct design that separates server-side code from client-side logic, resulting in faster processing times and better performance. This architecture employs server-side rendering (SSR) to generate HTML pages on the server, significantly reducing client-side load. Next.js apps also use a hybrid approach that utilizes dynamic and static rendering for increased efficiency and faster load times. Because of these features, Next.js is an excellent choice for programmers looking to create modern, powerful web applications.
The next topic that we will cover is authentication. So, let’s take a look at how certain security measures can enhance our defenses.
What authentication is available in Next.js applications?
The security of online apps is a high priority as they become more essential to our daily lives. A key component of protecting these applications is authentication, which is the method of confirming a user’s identity. Providing authentication in a Next.js application can be done using a variety of techniques, including the following:
- Auth.js
- JSON Web Tokens (JWTs)
- Auth0
- OAuth2
- Login and password authentication
By utilizing these technologies, engineers can defend their applications against online threats such as hackers’ attempts to steal user data. This high degree of verification guarantees users a safe and reliable environment while also safeguarding their private data. A Next.js application must use proper authentication procedures given the growing significance of online privacy.
Speed is a high-priority requirement when building our app infrastructure, but how does SWR make it better? We will find out now in the next section.
How does SWR allow fast data retrieval?
It is not surprising that quick and effective data fetching has elevated to the top of developers’ priorities as the world becomes increasingly data-driven. And that’s where stale-while-revalidate, or SWR, comes into play. SWR is a remote data fetching React Hooks library that prioritizes speed, caching, and revalidation. Fetching data is made simple with SWR, since it does away with annoying loading boxes and makes sure the data is continuously current. Additionally, it has a user-friendly API that makes it simple for programmers of any experience level to utilize.
Now, we will take another look at GraphQL to see why it has become the best choice for modern application architecture.
How can GraphQL integration optimize our data fetching?
The need to optimize productivity and simplify operations grows as technology develops. In response, GraphQL integration has become more common. GraphQL significantly boosts the speed and accuracy of data retrieval by enabling optimized data fetching. With GraphQL, queries can be customized to meet particular needs rather than having to get several datasets and sort through them to find the necessary information. The outcome of this is that data can be retrieved more quickly and accurately, which can aid companies in staying current. Because of these advantages, many businesses have adopted GraphQL integration, given its capacity to improve data fetching procedures.
Deployment is where our application goes live online for the public to use and we get to show off our creation to the world. So, let’s now learn about this crucial step in the next section.
How do we deploy our Next.js applications online?
Deploying apps on cloud platforms is the conclusion of all of our hard work, and this process can be both challenging and rewarding. The best feature (which makes Next.js a favorite among developers) is that it allows SSR. Our Next.js application will now be accessible at all times and from any location when we deploy it on a cloud infrastructure. Numerous cloud providers are readily accessible on the market, each with distinctive characteristics.
One of the most popular online cloud host providers is Vercel, the creators of Next.js, meaning that their platform is the perfect place for deploying our Next.js apps. Other popular serverless host providers include Netlify, AWS, Azure, Render, Firebase, and Supabase. There are countless others out there to choose from. The important thing is to find a platform that is cost-effective and offers many good features and services. The majority of the ones mentioned here offer free services.
Finally, we will end this section by checking out ways to scale and maintain our application once it has been deployed to manage its growth.
What strategies can we use for scaling and maintaining our application architecture as it grows?
It’s critical to have a plan developed for expanding as well as sustaining our architecture as the popularity and usage of our application grows. Without proper planning, our application might not be able to cope with the surge in traffic, which could turn off prospective customers. Forecasting and taking into account potential future growth, along with the tools and technology that might assist us in getting there, are necessary for a scalable design. The continuous effectiveness of an app is also greatly dependent on the upkeep of our architecture as it develops. Adding user feedback to enhance the user experience, testing our software for faults and problems, and routinely reviewing and revising the code base are all part of this. Our apps can thrive for a very long time if we put the correct plans in place.
Having an in-depth knowledge of authentication, SWR data fetching strategies, GraphQL integration, and deployment strategies will greatly benefit us as we start to develop the architecture of our Next.js application. With these plans in place, we can start thinking about scaling and managing our application as it grows, which is a vital component of any effective application architecture. The strength of Next.js, combined with these strategies, will result in an excellent user experience and contribute to the efficiency of the development process.
Working on our coffee restaurant project
With the theory out of the way, let’s start building our website. The first thing we need to do is set up our project, so let’s do that now.
Our technical stack is as follows:
- Next.js: React framework
- styled-components: CSS styling
- apollographql: Data API
- authjs: Authentication
- React Testing Library and Jest: Testing
- GitHub: Version control
- Vercel: Serverless online web host
We are going to create a restaurant application for this project. There will be five main pages, and two of them will require you to be authenticated to access them. The authentication will be taken care of with Google or GitHub, so you can use either account to sign in.
This is what the final project will look like for our app:
Figure 12.4: Next.js final project home page
The project and code base can be found online at https://github.com/PacktPublishing/React-Interview-Guide/tree/main/Chapter12/coffee-restaurant
and there is a link on GitHub to a working website, so you can see all of the pages.
Building the business logic
Now, with the theory completed, we are ready to do some practical work as we build our application. It’s going to be a fairly simple application; the main aim here is to understand how we connect all of these technologies. The application will be a restaurant website that has some restricted pages that require an authenticated user to access them. These authenticated pages will only show the data from our GraphQL API if the user is logged in; otherwise, they will be presented with a sign-in page.
With that introduction out of the way, let’s begin building the business logic.
Create a folder on your computer, such as on the desktop, and then run the following Next.js command to create a Next.js project:
npx create-next-app my-app-restaurant
You can use the following settings:
- Would you like to use TypeScript with this project? … No/Yes
- Would you like to use ESLint with this project? … No/Yes
- Would you like to use Tailwind CSS with this project? … No/Yes
- Would you like to use `src/` directory with this project? … No/Yes
- Use App Router (recommended)? … No/Yes
- Would you like to customize the default import alias? … No/Yes
Now, we have to install all of the dependencies and packages for our project. So cd into the my-app-restaurant directory and run the following commands to install the packages.
Run the following script to install the regular dependencies:
npm i @apollo/client @apollo/server @as-integrations/next @testing-library/user-event graphql graphql-tag next-auth styled-components@latest
Run the following script to install the development dependencies:
npm i --save-dev @testing-library/jest-dom @testing-library/react jest jest-environment-jsdom
Note
If you encounter any errors when trying to install these packages you could try adding the --force command or using sudo if you are on a Mac like this: sudo npm i --save-dev @testing-library/jest-dom @testing-library/react jest jest-environment-jsdom --force
Now, add the following test run script to the scripts section in the package.json file in the root folder:
"test": "jest --watch",
Now, run this command inside the root of the my-app-restaurant folder. This will create all of the files and folders we will need for this project:
mkdir data
touch data/menu.js data/profile.js
touch .env.local jest.config.mjs
cd src/app
mkdir account account/menu account/profile
touch account/menu/page.js account/profile/page.js
mkdir api api/auth api/auth/"[...nextauth]"
touch api/auth/"[...nextauth]"/route.js
mkdir components graphql lib nutrition queries rewards utils
touch components/GlobalStyles.js components/MainMenu.js components/Provider.js
touch graphql/route.js
touch lib/registry.js
touch nutrition/page.js nutrition/page.test.js
touch queries/clientQueries.js
touch utils/withApollo.js utils/cors.js
touch not-found.js page.test.js
Before we start to work on the main app files, let’s sort out the configuration files first.
Configuration files setup
Put this code in the api/auth/[…nextauth]/route.js file. We will use this code for setting up our authentication layer, in which GitHub and Google will be used for signing in to the protected routes:
import NextAuth from 'next-auth';
import GithubProvider from 'next-auth/providers/github';
import GoogleProvider from 'next-auth/providers/google';
export const handler = NextAuth({
providers: [
GithubProvider({
clientId: process.env.GITHUB_ID,
clientSecret: process.env.GITHUB_SECRET,
}),
GoogleProvider({
clientId: process.env.GOOGLE_ID,
clientSecret: process.env.GOOGLE_SECRET,
}),
],
});
export { handler as GET, handler as POST }; Next, put this code in the lib/registry.js file. This code is used for configuring styled-components to work with Next.js:
use client';
import React, { useState } from 'react';
import { useServerInsertedHTML } from 'next/navigation';
import { ServerStyleSheet, StyleSheetManager } from 'styled-components';
export default function StyledComponentsRegistry({ children }) {
// Only create stylesheet once with lazy initial state
// x-ref: https://reactjs.org/docs/hooks-reference.html#lazy-initial-state
const [styledComponentsStyleSheet] = useState(() => new ServerStyleSheet());
useServerInsertedHTML(() => {
const styles = styledComponentsStyleSheet.getStyleElement();
styledComponentsStyleSheet.instance.clearTag();
return <>{styles}</>;
});
if (typeof window !== 'undefined') return <>{children}</>;
return (
<StyleSheetManager sheet={styledComponentsStyleSheet.instance}>
{children}
</StyleSheetManager>
);
} Now, add the following code to the jest.config.mjs file in the root directory. This file can be used for setting up the Jest test runner:
import nextJest from 'next/jest.js';
const createJestConfig = nextJest({
// Provide the path to your Next.js app to load next.config.js and .env files in your test environment
dir: './',
});
// Add any custom config to be passed to Jest
/** @type {import('jest').Config} */
const config = {
// Add more setup options before each test is run
// setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
testEnvironment: 'jest-environment-jsdom',
};
// createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
export default createJestConfig(config); Now, update the next.config.js file in the root folder with this code, which will enable styled-components to work as well as the app directory setup:
/** @type {import('next').NextConfig} */
const nextConfig = {
compiler: {
styledComponents: true,
},
};
module.exports = nextConfig; We just have one more step to complete, which is the GitHub and Google authentication setup section. We must create IDs and secrets for our .env.local file. The authentication setup can be found at https://authjs.dev/getting-started/oauth-tutorial. The tutorial shows you how to do the authentication setup with GitHub. However, the setup is fairly similar for other authentication providers, and you can find the one for Google at https://developers.google.com/identity/protocols/oauth2.
Just remember that when we run our app locally, the callback URL will look something like this if we use GitHub as an example: http://localhost:3000/api/auth/callback/github.
When we deploy it online, it might look something like this: https://your-app-url.vercel.app/api/auth/callback/github.
This is important because our authenticated routes won’t work unless we use the right URL. Finally, we just need to add the IDs and secrets to our .env.local file. This file also needs a secret to be created for our NEXTAUTH_SECRET key-value pair, which is required for NextAuth.js:
NEXTAUTH_SECRET="yournextsecret"
GITHUB_ID="yourgithubid"
GITHUB_SECRET="yourgithubsecret"
GOOGLE_ID="yourgoogleid"
GOOGLE_SECRET="yourgooglesecret"
You can create your own secret key, and it can be anything you want; I would suggest making it secure by generating a random string of characters as you would if you were creating a strong password. There are many free tools that can do this for you, or you could just randomly make one yourself, such as this example: Y@q7LH@6YoBa$Dkz. It uses both uppercase and lowercase alphanumeric characters and it also has special characters. We all know how to create secure passwords; just use the same thinking when creating your secret key.
Building the app
Let’s go for it! There are quite a lot of files because the build phase has many files. But after this section, we will be close to completion! We have a data layer that will act as our database. Basically, there is an array of objects that we will fetch using GraphQL and then display on our frontend.
Use the following code inside the data folder we created. This code will be for the data we show on the Menu page, so put it in the data/menu.js file:
export const menu = [
{
id: '1',
foodType: 'Drinks',
name: 'Latte',
description: 'Steamed milk',
},
{
id: '2',
foodType: 'Drinks',
name: 'Cappuccino',
description: 'Espresso',
},
]; Now, the following code is for data/profile.js:
export const profile = [
{
id: '1',
bio: `Born and raised in London, my name is Jordan Brewer and I am a passionate coffee aficionado with a heart as warm as a freshly brewed cup of java.`,
},
]; Moving on, the next batch of code is for the authenticated pages for the menu and profile.
The following code is for account/menu/page.js.
This code is quite long so let’s break it down into smaller code blocks. This first code block has our imports and color theme setup:
'use client';
import { useSession, signIn, signOut } from 'next-auth/react';
import { useQuery } from '@apollo/client';
import { GET_MENU } from '@/app/queries/clientQueries';
import withApollo from '../../utils/withApollo';
import { styled, ThemeProvider } from 'styled-components';
import GlobalStyle from '../../components/GlobalStyles';
import MainMenu from '../../components/MainMenu';
const theme = {
colors: {
primary: 'rgb(15 23 42)',
},
}; The next code block has our CSS and styled-components:
const MainContainer = styled.div`
margin: 2rem auto;
max-width: 120rem;
padding: 2rem;
width: 100%;
`;
const PageTitle = styled.h1`
color: #ffffff;
`;
const LoginStatus = styled.p`
color: #ffffff;
`;
const SignInOutButton = styled.button`
color: #ffffff;
padding: 0.5rem;
cursor: pointer;
margin: 2rem 0 2rem 0;
`;
const ContentContainer = styled.div`
display: flex;
flex-flow: column wrap;
`;
const Content = styled.p`
color: #ffffff;
font-size: 1.4rem;
`;
const ItemContainer = styled.div`
display: flex;
flex-flow: row nowrap;
margin: 2rem 0 2rem 0;
border: 0.1rem solid black;
`;
const ItemDescription = styled.div`
margin-left: 1rem;
`;
And lastly, we have the rendered data for our application:
const Menu = () => {
const { loading, error, data } = useQuery(GET_MENU);
const { data: session, status } = useSession();
const userEmail = session?.user?.email;
if (loading) return <Content>Loading...</Content>;
if (error) return <Content>Something
went wrong</Content>;
if (status === 'loading') {
return <Content>Hang on there...</Content>;
}
if (status === 'authenticated') {
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainMenu />
<MainContainer>
<PageTitle>Menu</PageTitle>
<LoginStatus>Signed in as {userEmail}</LoginStatus>
<SignInOutButton onClick={() => signOut()}>
Sign out
</SignInOutButton>
{!loading && !error && (
<ContentContainer>
{data.menu.map((items) => (
<ContentContainer key={items.id}>
<ItemContainer>
<ItemDescription>
<Content>{items.name}</Content>
<Content>{items.foodType}</Content>
<Content>{items.description}
</Content>
</ItemDescription>
</ItemContainer>
</ContentContainer>
))}
</ContentContainer>
)}
</MainContainer>
</ThemeProvider>
</>
);
}
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainMenu />
<MainContainer>
<PageTitle>Menu</PageTitle>
<SignInOutButton onClick={() => signIn('')}>
Sign in</SignInOutButton>
<LoginStatus>Not signed in. Sign in to view
the menu.</LoginStatus>
</MainContainer>
</ThemeProvider>
</>
);
};
export default withApollo(Menu); Now, the following code is for account/profile/page.js.
Like last time, let’s break it down into smaller code blocks.
First, we have the imports for our page:
'use client';
import { useSession, signIn, signOut } from 'next-auth/react';
import { useQuery } from '@apollo/client';
import { GET_PROFILE } from '@/app/queries/clientQueries';
import withApollo from '../../utils/withApollo';
import { styled, ThemeProvider } from 'styled-components';
import GlobalStyle from '../../components/GlobalStyles';
import MainMenu from '../../components/MainMenu'; Now, we have the color theme and styled-components code:
const theme = {
colors: {
primary: 'rgb(15 23 42)',
},
};
const MainContainer = styled.div`
margin: 2rem auto;
max-width: 120rem;
padding: 2rem;
width: 100%;
`;
const PageTitle = styled.h1`
color: #ffffff;
`;
const LoginStatus = styled.p`
color: #ffffff;
`;
const SignInOutButton = styled.button`
color: #ffffff;
padding: 0.5rem;
cursor: pointer;
margin: 2rem 0 2rem 0;
`;
const ContentContainer = styled.div`
display: flex;
flex-flow: row wrap;
`;
const Content = styled.p`
color: #ffffff;
font-size: 1.4rem;
margin-top: 2rem;
`; Lastly, we have the rendered content for the page:
const ClientProtectPage = () => {
const { loading, error, data } = useQuery(GET_PROFILE);
const { data: session, status } = useSession();
const userEmail = session?.user?.email;
if (loading) return <Content>Loading...</Content>;
if (error) return <Content>Something went wrong
</Content>;
if (status === 'loading') {
return <Content>Hang on there...</Content>;
}
if (status === 'authenticated') {
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainMenu />
<MainContainer>
<PageTitle>Profile</PageTitle>
<LoginStatus>Signed in as {userEmail}
</LoginStatus>
<SignInOutButton onClick={() => signOut()}>
Sign out
</SignInOutButton>
{!loading && !error && (
<ContentContainer>
{data.profile.map((account) => (
<ContentContainer key={account.id}>
<Content>{account.bio}</Content>
</ContentContainer>
))}
</ContentContainer>
)}
</MainContainer>
</ThemeProvider>
</>
);
}
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainMenu />
<MainContainer>
<PageTitle>Profile</PageTitle>
<SignInOutButton onClick={() => signIn('')}>
Sign in</SignInOutButton>
<LoginStatus>
Not signed in. Sign in to view your profile.
</LoginStatus>
</MainContainer>
</ThemeProvider>
</>
);
};
export default withApollo(ClientProtectPage); Now, let’s work on some component files. The first code is for components/MainMenu.js:
import Link from 'next/link';
import { styled } from 'styled-components';
const MainNavigation = styled.nav`
position: relative;
z-index: 1;
display: flex;
flex-flow: wrap;
justify-content: space-around;
font-size: 2rem;
padding: 1rem;
background: rgb(250 250 250);
`;
export default function MainMenu() {
return (
<MainNavigation>
<Link href="/">Home</Link>
<Link href="/nutrition">Nutrition</Link>
<Link href="/account/menu">Menu</Link>
<Link href="/account/profile">Profile</Link>
</MainNavigation>
);
} Next, the following code is for the components/Provider.js file, which is required for authentication and session state:
'use client';
import { SessionProvider } from 'next-auth/react';
const Provider = ({ children }) => {
return <SessionProvider>{children}</SessionProvider>;
};
export default Provider; Our next file has our GraphQL schema, resolvers, and our Apollo server. The following code goes in graphql/route.js:
mport { ApolloServer } from '@apollo/server';
import { startServerAndCreateNextHandler } from '@as-integrations/next';
import { gql } from 'graphql-tag';
import { menu } from '../../../data/menu';
import { profile } from '../../../data/profile';
import allowCors from '../utils/cors';
// Define the GraphQL schema and resolvers
const typeDefs = gql`
type Menu {
id: String
foodType: String
name: String
description: String
}
type Profile {
id: String
bio: String
}
type Query {
menu: [Menu]
profile: [Profile]
}
`;
const resolvers = {
Query: {
menu: () => menu,
profile: () => profile,
},
};
// Create the Apollo Server
const server = new ApolloServer({
typeDefs,
resolvers,
});
const handler = startServerAndCreateNextHandler(server, {
context: async (req, res) => ({ req, res }),
});
export async function GET(request) {
return handler(request);
}
export async function POST(request) {
return handler(request);
}
export default allowCors(handler); Now, use the following code to build nutrition/page.js:
'use client';
import { styled, ThemeProvider } from 'styled-components';
import GlobalStyle from '../components/GlobalStyles';
import MainMenu from '../components/MainMenu';
const theme = {
colors: {
primary: 'rgb(15 23 42)',
},
};
const MainContainer = styled.div`
margin: 2rem auto;
max-width: 120rem;
padding: 2rem;
width: 100%;
`;
const PageTitle = styled.h1`
color: #ffffff;
`;
const PageIntro = styled.p`
color: #ffffff;
margin-top: 2rem;
font-size: 1.4rem;
`;
export default function Nutrition() {
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainMenu />
<MainContainer>
<PageTitle>Nutrition</PageTitle>
<PageIntro>Nutrition is good for health
and diet!</PageIntro>
</MainContainer>
</ThemeProvider>
</>
);
} GraphQL queries are next, so the following code is for the queries/clientQueries.js file:
import { gql } from '@apollo/client';
const GET_MENU = gql`
query {
menu {
id
name
foodType
description
}
}
`;
const GET_PROFILE = gql`
query {
profile {
id
bio
}
}
`;
export { GET_MENU, GET_PROFILE }; Now, the important utils/cors.js file is needed so that we don’t get CORS errors when our app is deployed online. This will allow us to access our GraphQL API on the authenticated routes:
const allowCors = (fn) => async (req, res) => {
res.setHeader('Access-Control-Allow-Credentials', true);
res.setHeader('Access-Control-Allow-Origin', '*');
res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader(
'Access-Control-Allow-Methods',
'GET,OPTIONS,PATCH,DELETE,POST,PUT'
);
res.setHeader(
'Access-Control-Allow-Headers',
'X-CSRF-Token, X-Requested-With, Accept, Accept-Version,
Content-Length, Content-MD5, Content-Type, Date, X-Api-Version'
);
if (req.method === 'OPTIONS') {
res.status(200).end();
return;
}
await fn(req, res);
};
export default allowCors; Let’s keep going. We have some more code here and it’s for another GraphQL setup page; this time, it has the endpoints for GraphQL, which is how we will access our queries later. This file is in utils/withApollo.js:
import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client';
import { useMemo } from 'react';
import { SessionProvider } from 'next-auth/react';
export function initializeApollo(initialState = null) {
const _apolloClient = new ApolloClient({
// Local GraphQL endpoint
// uri: 'http://localhost:3000/graphql',
// Your online GraphQL endpoint
uri: 'https://coffee-restaurant.vercel.app/graphql',
cache: new InMemoryCache().restore(initialState || {}),
});
return _apolloClient;
}
export function useApollo(initialState) {
const store = useMemo(() => initializeApollo(initialState),
[initialState]);
return store;
}
export default function withApollo(PageComponent) {
const WithApollo = ({ apolloClient, apolloState, session,
...pageProps }) => {
const client = useApollo(apolloState);
return (
<SessionProvider session={session}>
<ApolloProvider client={client}>
<PageComponent {...pageProps} />
</ApolloProvider>
</SessionProvider>
);
};
// On the server
if (typeof window === 'undefined') {
WithApollo.getInitialProps = async (ctx) => {
const apolloClient = initializeApollo();
let pageProps = {};
if (PageComponent.getInitialProps) {
pageProps = await PageComponent.getInitialProps(ctx);
}
if (ctx.res && ctx.res.finished) {
// When redirecting, the response is finished.
// No point in continuing to render
return pageProps;
}
const apolloState = apolloClient.cache.extract();
return {
...pageProps,
apolloState,
};
};
}
return WithApollo;
} Almost done! We are now on the layout.js page file:
import './globals.css';
import { Dosis } from 'next/font/google';
import StyledComponentsRegistry from './lib/registry';
const dosis = Dosis({ subsets: ['latin'] });
export const metadata = {
title: 'Resturant App',
description: 'Generated by create next app',
};
export default function RootLayout({ children }) {
return (
<html lang="en">
<StyledComponentsRegistry>
<body className={dosis.className}>{children}</body>
</StyledComponentsRegistry>
</html>
);
} The 404 error not-found.js page has the following code:
'use client';
import { styled, ThemeProvider } from 'styled-components';
import GlobalStyle from '../../src/app/components/GlobalStyles';
import MainMenu from './components/MainMenu';
const theme = {
colors: {
primary: 'rgb(15 23 42)',
},
};
const MainContainer = styled.div`
margin: 2rem auto;
max-width: 120rem;
padding: 2rem;
width: 100%;
`;
const PageTitle = styled.h1`
color: #ffffff;
`;
const PageIntro = styled.p`
color: #ffffff;
margin-top: 2rem;
font-size: 1.4rem;
`;
export default function NotFound() {
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainMenu />
<MainContainer>
<PageTitle>Page Not Found</PageTitle>
<PageIntro>Could not find requested
page :(</PageIntro>
</MainContainer>
</ThemeProvider>
</>
);
} And lastly, the page.js file is in the root folder, which is our home page.
The code is split in two for readability. First, we have the imports and CSS section:
'use client';
import { styled, ThemeProvider } from 'styled-components';
import GlobalStyle from '../../src/app/components/GlobalStyles';
import MainMenu from './components/MainMenu';
const theme = {
colors: {
primary: 'rgb(15 23 42)',
},
};
const MainContainer = styled.div`
margin: 0 auto;
width: 100%;
`;
const CoverHeadingBG = styled.div`
margin: 2rem auto;
display: flex;
flex-flow: column;
align-items: center;
background-color: rgb(6 95 70);
color: rgb(255 255 255);
border-radius: 2rem;
padding: 2rem;
`;
const CoverHeading = styled.h1`
text-transform: uppercase;
`;
const CoverIntro = styled.p`
font-size: 1.4rem;
margin: 2rem 2rem;
`;
const Hero = styled.div`
margin: 2rem auto;
background-image: url('https://res.cloudinary.com/d74fh3kw/image/
upload/v1692557430/coffee-restaurant/coffee-shop_zlkf7u.jpg');
background-repeat: no-repeat;
background-size: cover;
background-position: center;
background-color: rgb(4 120 87);
height: 67.5rem;
width: 100%;
`;
export default function Home() {
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainContainer>
<MainMenu />
<CoverHeadingBG>
<CoverHeading>Summer time is here!</CoverHeading>
<CoverIntro>
Our summer menu has arrived. Freshen up your day with
our creamy
and delicious coffee range, iced teas and mouth watering
snacks.
</CoverIntro>
</CoverHeadingBG>
<Hero></Hero>
</MainContainer>
</ThemeProvider>
</>
);
} And now for the function where we render our components in JSX with HTML:
export default function Home() {
return (
<>
<ThemeProvider theme={theme}>
<GlobalStyle />
<MainContainer>
<MainMenu />
<CoverHeadingBG>
<CoverHeading>Summer time is here!</CoverHeading>
<CoverIntro>
Our summer menu has arrived. Freshen up your day with
our creamy
and delicious coffee range, iced teas and mouth watering
snacks.
</CoverIntro>
</CoverHeadingBG>
<Hero></Hero>
</MainContainer>
</ThemeProvider>
</>
);
} That’s it! We are done with the bulk of the code base, and our app is almost complete! All that is left is a GlobalStyles.js file and the images for the frontend. We will do this in the upcoming section.
Building the presentation layer
Our project uses styled-components, which means the component and page files already have localized CSS. We do have one global CSS file though, which is a styled component with global style. Here is the code for components/GlobalStyles.js:
import { createGlobalStyle } from 'styled-components';
const GlobalStyle = createGlobalStyle`
html,
body {
color: ${({ theme }) => theme.colors.primary};
padding: 0;
margin: 0;
font-size: 1rem;
background: rgb(6 78 59);
}
* {
box-sizing: border-box;
}
`;
export default GlobalStyle; We have waited long enough; it’s time to finally see our application running!
Make sure that you are in the root folder for my-app-restaurant and run the application with the npm run dev command.
Our application should be running on http://localhost:3000 and our GraphQL API should be on http://localhost:3000/graphql.
The GraphQL API has built-in documentation for testing our queries. Here is an example query that should return the menu data:
query {
menu {
id
name
foodType
description
}
} Before we put our app on GitHub and deploy it online, we will finish off with some unit tests for some of the files so that we get used to test-driven development.
Implementing testing
We have two test suites. First, we have the code for nutrition/page.test.js:
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect';
import Nutrition from './page';
describe('Nutrition', () => {
it('renders without crashing', () => {
render(<Nutrition />);
});
it('displays the correct title and intro', () => {
render(<Nutrition />);
expect(
screen.getByText('Nutrition is good for health and diet!')
).toBeInTheDocument();
});
}); And lastly, the following code is for the page.test.js file in the root folder:
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect';
import Home from './page';
describe('Home', () => {
it('renders without crashing', () => {
render(<Home />);
});
it('displays the correct heading and intro', () => {
render(<Home />);
expect(screen.getByText('Summer time is here!')).
toBeInTheDocument();
expect(
screen.getByText(
/Our summer menu has arrived. Freshen up your day with our
creamy and delicious coffee range, iced teas and mouth
watering snacks./
)
).toBeInTheDocument();
});
}); Run the npm test command, and all tests should be passing. You can press the A button to rerun all of the tests.
Our app is more or less complete. Let’s now put it on GitHub so that we can version control it. It is also preparation for getting our app to work online when we deploy it to Vercel, our serverless host.
Creating a Git repository with README documentation
Go to GitHub and create a new repo for our project. If you are new to or still unfamiliar with GitHub, then you can follow the Get started guide here: https://docs.github.com/en/get-started. Then, simply follow the commands to push your project to GitHub. These are the commands I used. Replace them with your own repo:
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/yourname/yourprojectname.git
git push -u origin main
Our project is now on GitHub! We only have one thing left to do – to deploy our app on Vercel – and then we are done!
Deploying the application for public access
Sign in to your Vercel account and then, on the dashboard, there should be a button to add a new project. Add a new project and import the Git repository you just created for the project.
Before you hit the Deploy button, you must enter your environment variables, which you will find in the .env.local file in the root folder of your project. This file was not uploaded to your GitHub repo because it has your GitHub and Google IDs and secret keys, which you don’t want people to see! When you’re done, hit Deploy and wait for the build to complete.
Our app should be live online now. However, the Menu and Profile pages will be broken. Don’t worry! This is expected because, in our code in the utils/withApollo.js file, the URL is set to http://localhost:3000/graphql; our app is online now and is not running on our machine, so the address needs to change. Update it to the address of your app on Vercel, as in the following example: https://your-app-url.vercel.app/graphql. Push the latest changes to your GitHub repository, and Vercel will automatically update and deploy with the new URI.
The following commit message should be fine:
git status
git add .
git commit -m "vercel graphql endpoint for uri"
git push
And remember from earlier, when we run our app locally, the callback URL will look something like this, if we use GitHub as an example: http://localhost:3000/api/auth/callback/github.
When deployed online, it will have the following type of URL structure: https://your-app-url.vercel.app/api/auth/callback/github.
So update the authentication for your app on GitHub and Google to get the Menu and Profile pages working online.
It should be all done. Now, our application should be available online for the whole world to see. Well done!
Summary
We have made it to the end of this chapter and leveled up our programming skills considerably. Right at the beginning of this chapter, we learned about REST APIs and how they help us to fetch data on the internet, which we can then use in our applications. Afterward, we had an introduction to planning application architecture, where we talked about authentication followed by SWR, an HTTP cache invalidation strategy. The next topic was GraphQL, the popular alternative to using REST APIs, which requires fewer API requests as it’s possible to fetch only the data we require. We then touched upon deployment because it’s important to remember this setup from the get-go.
In the next sections, we dived into business logic and learned why our code needs to be well refined. This section was followed up by the presentation layer as we created a design that used styled-components. Testing was factored in, and we learned how to test the code that we wrote for our project. With our application completed, the final step was its deployment, and this is where we learned about creating a Git repository that has a README file with our documentation. In this step, we also put our application online so that it was publicly available for everyone to use.
With everything that we have absorbed, it’s safe to say that we have taken a huge leap forward in terms of learning and have become much more talented programmers in the process. We are now better prepared to tackle interviews as job seekers.
