Frequently Asked Questions

Technical Features & Capabilities

What is dynamic routing in Next.js and how does it work?

Dynamic routing in Next.js allows you to generate routes based on external data sources, such as a database, at build time. By creating files or folders with names in square brackets (e.g., [id].js), you can match any route like /post/1, /post/2, etc. This enables you to statically generate pages for each route using getStaticPaths and getStaticProps. Note: This approach is best suited for scenarios where the number of routes is known at build time; for highly dynamic or user-generated content, server-side rendering or client-side rendering may be more appropriate.

How does pre-rendering work in Next.js?

Pre-rendering in Next.js means generating HTML for your pages in advance, rather than on each request. There are two main types: static generation (HTML generated at build time for static content) and server-side rendering (HTML generated on each request for dynamic content). This improves performance and SEO. Note: Static generation is optimal for content that doesn't change often; for frequently updated data, server-side rendering may be preferable.

What are getStaticProps and getStaticPaths in Next.js?

getStaticProps is a Next.js function that fetches data at build time and passes it as props to your page component. getStaticPaths is used with dynamic routes to specify which paths should be pre-rendered. Together, they enable static generation of dynamic routes, such as blog posts fetched from an external source. Note: These functions only run at build time and are not suitable for data that changes frequently unless you use incremental static regeneration.

How can Hygraph be used with Next.js for dynamic routing?

Hygraph can serve as the external data source for your Next.js application. You can use Hygraph's GraphQL Content API to fetch content (such as blog posts) and generate dynamic routes at build time using getStaticPaths and getStaticProps. This enables you to statically generate pages for each content item managed in Hygraph. Note: For real-time updates or highly dynamic content, consider using server-side rendering or client-side fetching in addition to static generation.

Hygraph Product Features & Integrations

What APIs does Hygraph provide for integrating with Next.js or other frameworks?

Hygraph offers several APIs: the GraphQL Content API for querying and manipulating content, the Management API for handling project structure, the Asset Upload API for uploading files, and the MCP Server API for AI assistant integration. These APIs are optimized for high performance and low latency. Note: Some advanced features may require familiarity with GraphQL or the Hygraph Management SDK. Learn more in the API Reference documentation.

What integrations does Hygraph support?

Hygraph supports integrations with Digital Asset Management (DAM) systems such as Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, and Scaleflex Filerobot; hosting and deployment platforms like Netlify and Vercel; Product Information Management (PIM) with Akeneo; commerce solutions like BigCommerce; and translation/localization tools such as EasyTranslate. For a full list, visit the Hygraph Marketplace. Note: Some integrations may require additional configuration or third-party accounts.

What are the key features and benefits of using Hygraph?

Hygraph is a GraphQL-native Headless CMS that simplifies schema evolution, enables content federation (integrating multiple data sources without duplication), and offers enterprise-grade features such as Smart Edge Cache, localization, and granular permissions. It is recognized for its user-friendly interface, scalability, and proven ROI (e.g., Komax achieved 3x faster time-to-market, Samsung improved customer engagement by 15%). Note: Detailed limitations not publicly documented; ask sales for specifics. See Komax case study.

Implementation, Support & Documentation

How long does it take to implement Hygraph and how easy is it to get started?

Implementation time varies by project complexity. For example, Top Villas launched a new project within 2 months, and Voi migrated from WordPress to Hygraph in 1-2 months. Hygraph offers structured onboarding, extensive documentation, starter projects, and community support to help users get started quickly. Note: Highly customized or enterprise migrations may require additional planning. See Top Villas case study.

What technical documentation is available for Hygraph users?

Hygraph provides comprehensive technical documentation, including API references, schema component guides, getting started tutorials, integration guides (e.g., Mux, Akeneo, Auth0), and AI feature documentation. Classic documentation is available for legacy users. Note: Some advanced topics may require prior experience with GraphQL or headless CMS concepts. Explore Hygraph Documentation.

Security & Compliance

What security and compliance certifications does Hygraph hold?

Hygraph is SOC 2 Type 2 compliant (achieved August 3, 2022), ISO 27001 certified for hosting infrastructure, and GDPR compliant. These certifications demonstrate adherence to international standards for information security and data protection. Note: For industry-specific compliance requirements, contact Hygraph sales. See Secure Features.

What security features does Hygraph provide?

Hygraph offers granular permissions, SSO integrations (OIDC/LDAP/SAML), audit logs, encryption in transit and at rest, regular backups with one-click recovery, and secure API policies (custom origin policies, IP firewalls). All endpoints have SSL certificates. Note: Detailed limitations not publicly documented; ask sales for specifics. Learn more about Hygraph security.

Performance & Customer Feedback

How does Hygraph perform in terms of content delivery and API speed?

Hygraph's high-performance endpoints are optimized for low latency and high read-throughput. The read-only cache endpoint delivers 3-5x latency improvement. Hygraph actively measures GraphQL API performance and provides optimization advice. Note: Actual performance may vary based on project complexity and integration setup. Read more about performance improvements.

What feedback have customers given about Hygraph's ease of use?

Customers highlight Hygraph's intuitive interface, quick adaptability, and user-friendly setup. For example, Sigurður G. (CTO) praised the UI as intuitive for non-technical users; Anastasija S. (Product Content Coordinator) noted instant front-end updates; and Charissa K. (Senior CMS Specialist) emphasized the clear setup and localization features. Note: Some advanced configurations may require technical expertise. See more customer feedback.

Use Cases, Industries & Customer Success

Who can benefit from using Hygraph?

Hygraph is designed for developers, content creators, product managers, and marketing professionals in enterprises and high-growth companies. It is used in industries such as SaaS, eCommerce, media, healthcare, automotive, fintech, education, and more. Note: For highly specialized industry requirements, consult Hygraph sales. See case studies by industry.

What business impact can customers expect from using Hygraph?

Customers have achieved faster time-to-market (e.g., Komax: 3x faster), improved customer engagement (Samsung: +15%), cost reduction, and enhanced content consistency. AutoWeb saw a 20% increase in website monetization, and Voi scaled multilingual content across 12 countries and 10 languages. Note: Results may vary based on implementation scope. See all case studies.

Can you share specific case studies or customer success stories?

Yes. Notable examples include Samsung (15% improved engagement), Komax (3x faster time-to-market), AutoWeb (20% increase in monetization), Voi (multilingual scaling across 12 countries), and Dr. Oetker (enhanced digital experience with MACH architecture). See more at Hygraph's case studies page. Note: Outcomes depend on project scope and execution.

Pain Points & Problems Solved

What common pain points does Hygraph address?

Hygraph addresses operational inefficiencies (reducing developer dependency, modernizing legacy tech stacks, ensuring content consistency), financial challenges (lowering operational costs, accelerating speed-to-market, supporting scalability), and technical issues (simplifying schema evolution, integrating third-party systems, optimizing performance, and managing localization/assets). Note: Some highly specialized workflows may require custom development. See more on Hygraph FAQ.

LLM optimization

When was this page last updated?

This page wast last updated on 12/12/2025 .

Register now

Dynamic Routing in Next.js

As part of this tutorial, you will learn how to set up dynamic routing in Next.js, including pre-rendering, server-side rendering, and static generation.
Aagam Vadecha

Last updated by Aagam 

Jan 21, 2026

Originally written by Hygraph

Dynamic Routing in Next.js

#Pre Rendering

Next.js is a hybrid framework on top of React, which enables static and server-side rendering. It is packed with awesome features like file system routing, dynamic routing, image optimization, typescript support, code-splitting & bundling, etc., which are useful for any project. All in all, it is an impressive production framework for React.

When a page is loaded by the browser (client), its JavaScript code runs, making the page fully interactive. In addition to client-side rendering, Next.js offers pre-rendering for your views, which means that the HTML is generated in advance by Next.js and it need not rely on the client-side Javascript.

Pre-rendering can happen in two ways

  • Server-side
  • Static Generation

Server Side Rendering

When we cannot pre-render a page’s view ahead of a user's request, i.e in cases where we need to check the request and respond accordingly with a dynamically up-to-date page, we can either use server-side rendering or client-side rendering, as the data on the page depends on the request.

In server-side rendering, the request is received from the client, the server then generates the HTML and sends it back to the client. So here, the server generates the HTML for each request.

Diagram of the Server-Side Rendering (SSR) flow, where the server generates HTML in each request

Static Generation

When the data on a page is static, i.e. it doesn’t matter who is requesting, the response will always be the same. For instance, for a blog post, it doesn’t matter who requests it, it would always deliver the same content.

Since we have to deliver the same page, we can pre-render it during build time i.e statically generate it. This will result in faster responses than client-side or server-side rendering as the HTML page is generated at the build time itself and not run time.

In the case of a blog application, our static frontend pages in a Next.js App can be structured as below

/pages/post/post1.js
/pages/post/post2.js
/pages/post/post3.js

When we run the next build command, these pages will be statically generated once and the same copy can be quickly served to the users every time.

Diagram showing Static generation, where next build creates HTML at build-time to be reused for each request

Now let’s say that we want to add 10 more blogs, one option to do so is to create additional static react components for each and every blog like post4.jsx, post5.jsx, post6.jsx, and so on, and then build and deploy it. One caveat with this approach is that it will probably duplicate the same code over and over, and create additional components. This is not a neat scalable solution, imagine the code directory of a blog site with thousands of blogs built with this approach.

We need a way to dynamically generate any number of routes and we need to do that at build time in order to serve statically pre-rendered pages. Next.js supports dynamic routing which helps us to achieve this kind of use case. Let us try to learn more about dynamic routing with the help of an example.

#Example

Use Case

We want to build a simple frontend blog application, it should use Static Site Generation in a way that it will dynamically create any number of routes (example: post/1, post/post2, post/3, ... post/n). The number of routes can vary and can come from an external data source (eg: a database), The pages should be statically generated at build time, so we do not have to server side render them on run time. We assume that you are comfortable with the basics of Next.js and React and that you have a Next.js app up and running.

If you are not familiar with Next.js, we recommend you to go through some articles below and get started.

Mocking API Data

Let us create two simple functions that will provide data to our application. For demo purposes we have mocked data in this frontend itself. In a real-world application, you would want to replace this dummy data with actual API calls to get data from your data source.

First, add a function getPostIdList() that will return the list of posts in the format below.

lib/posts.js

export async function getPostIdList() {
return [{
params: {
id: '1'
}
}, {
params: {
id: '2'
}
}, {
params: {
id: '3'
}
}]
}

Two important things to note here are:

  • The response array should have the same format as shown above, this will help next.js to generate paths for our routes dynamically. We used id as our inner key since we will be creating our dynamic route component ahead as pages/post/[id].js .If our dynamic route component would have been /pages/post/[postId].js, we would use postId as the key here.
  • Next.js requires the value corresponding to the id key to be always a string.

Now, let's add another function getPostDetails() that will return some dummy data for each post.

lib/posts.js

export async function getPostDetails(postId) {
const dataSet = {
'1': {
title: 'Post 1',
description: 'Lorem ipsum dolor sit amet...',
date: 'Oct 10, 2022'
},
'2': {
title: 'Post 2',
description: 'Lorem ipsum dolor sit amet...',
date: 'Oct 20, 2022'
},
'3': {
title: 'Post 3',
description: 'Lorem ipsum dolor sit amet...',
date: 'Oct 30, 2022'
}
}
return dataSet[postId]
}

Adding a Dynamic Route Component

We want to display our blog on routes like /post/1, /post/2, etc. In Next.js, we can create a dynamic segment by wrapping file or folder name in square brackets like this [segmentName] . For our use case let us create a dynamic route component at pages/post/[id].js, any request in the browser like /post/1, /post/2, /post/a will match to this page.

Since each of our posts will have 3 fields - title, description, and date, we can render this simple template.

pages/post/[id].js

export default function Post({ postData }) {
return (
<div className='bg-gray-800 h-screen p-16 text-gray-100'>
<div className='text-center font-bold text-3xl'>
{postData.title}
</div>
<div className='text-justify my-8 text-gray-200'>
{postData.description}
</div>
<div className="text-gray-400">
Published On: {postData.date}
</div>
</div>
);
}

getStaticPaths and getStaticProps

We have our data ahead of users request and we need to pre-render our component at build time. Our component expects a postData prop, we just need a way to provide this prop to our component at build time.

getStaticProps method from Next.js allows us to do this. Let us add it to our component as shown below

export async function getStaticProps({ params }) {
const postData = await getPostDetails(params.id);
return {
props: {
postData,
},
};
}

We expect getStaticProps function to get the route parameters as an input. It can then use that post id and our mocked API function getPostDetails to get postData. Then it returns the postData in the format shown above. That’s it, Next.js will ensure our component function will get the postData prop.

Whenever we use dynamic routes and getStaticProps. We will need to also use getStaticPaths method provided by Next.js. When we export a function called getStaticPaths (Static Site Generation) from a page that uses dynamic routes, Next.js will statically pre-render all the paths specified by getStaticPaths. Also, in the above code getStaticProps is expecting params object which contains the post id that is needed to retrieve the post data. getStaticPaths can also be used to provide the params object to getStaticProps. Let us use it as shown below:

pages/post/[id].js

import { getPostDetails, getPostIdList } from '../../lib/posts';
export async function getStaticPaths() {
const paths = await getPostIdList();
return {
paths,
fallback: false,
};
}

getStaticPaths() gets the list of paths from our mocked API function getPostIdList() and Next.js will generate the respective routes and also pass the context ahead to getStaticProps.

In production, both getStaticProps and getStaticPaths will run only at the server at build time, it will not run on runtime.

Below is our final component

pages/post/[id].js

import { getPostDetails, getPostIdList } from '../../lib/posts';
export async function getStaticPaths() {
const paths = await getPostIdList();
return {
paths,
fallback: false,
};
}
export async function getStaticProps({ params }) {
const postData = await getPostDetails(params.id);
return {
props: {
postData,
},
};
}
export default function Post({ postData }) {
return (
<div className='bg-gray-800 h-screen p-16 text-gray-100'>
<div className='text-center font-bold text-3xl'>
{postData.title}
</div>
<div className='text-justify my-8 text-gray-200'>
{postData.description}
</div>
<div className="text-gray-400">
Published On: {postData.date}
</div>
</div>
);
}

dynamic route 1 dynamic route 2

Blog Authors

Share with others

Sign up for our newsletter!

Be the first to know about releases and industry news and insights.