How do you type getServerSideProps?

When working with Next.js, typing `getServerSideProps` correctly is a common question, especially if you want to maintain type safety and improve developer experience in a TypeScript codebase. Since `getServerSideProps` is a server-side function that fetches data at request time, understanding how to type it properly helps avoid runtime errors and makes your code easier to maintain.

I'll walk you through what `getServerSideProps` is, why typing it matters, how to type it correctly, and some practical tips and pitfalls I've encountered in real projects.

What is getServerSideProps?

`getServerSideProps` is a Next.js data-fetching method that runs on the server on every request. It allows you to fetch data dynamically and pass it as props to your page component. Unlike `getStaticProps`, which runs at build time, `getServerSideProps` runs on each request, making it ideal for pages that need fresh data or depend on request-specific information like headers or cookies.

Here’s a quick example:

export async function getServerSideProps(context) {
  const res = await fetch('https://api.example.com/data')
  const data = await res.json()

  return {
    props: { data }, // will be passed to the page component as props
  }
}

Why Type getServerSideProps?

Typing `getServerSideProps` is more than just a nicety. It helps catch bugs early, documents the shape of your data, and improves IDE autocompletion. Without proper types, you risk runtime errors due to unexpected data shapes or missing properties. This is especially important when your data comes from external APIs or databases.

Typing also clarifies what your page component expects as props, making it easier for other developers (or your future self) to understand the contract between server-side data fetching and the UI.

How to Type getServerSideProps Correctly

Next.js provides built-in TypeScript types to help with this. The main type you want to use is GetServerSideProps from the next package.

Here’s a step-by-step approach:

1. Define the Props Interface

First, define an interface or type for the props your page component will receive.

interface PageProps {
  data: {
    id: number
    name: string
    description: string
  }
}

2. Use GetServerSideProps with Your Props

Import the type and annotate your `getServerSideProps` function:

import { GetServerSideProps } from 'next'

export const getServerSideProps: GetServerSideProps<PageProps> = async (context) => {
  const res = await fetch('https://api.example.com/data')
  const data = await res.json()

  // You can add validation here to ensure data matches PageProps.data shape

  return {
    props: { data },
  }
}

This tells TypeScript that the props returned from `getServerSideProps` will match the `PageProps` interface. If you return something else, TypeScript will warn you.

3. Type Your Page Component

To keep things consistent, type your page component props as well:

import { NextPage } from 'next'

const Page: NextPage<PageProps> = ({ data }) => {
  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
    </div>
  )
}

export default Page

Real-World Example: Handling Query Parameters

Sometimes you need to access query parameters or cookies in `getServerSideProps`. The `context` parameter is typed as GetServerSidePropsContext, which gives you typed access to params, query, req, and res.

Example:

import { GetServerSideProps } from 'next'

interface PageProps {
  userId: string
  userData: {
    name: string
    email: string
  }
}

export const getServerSideProps: GetServerSideProps<PageProps> = async (context) => {
  const { userId } = context.query

  if (typeof userId !== 'string') {
    return {
      notFound: true,
    }
  }

  const res = await fetch(`https://api.example.com/users/${userId}`)
  const userData = await res.json()

  return {
    props: {
      userId,
      userData,
    },
  }
}

Here, we check that userId is a string before using it, which is a common source of bugs if you forget to validate query parameters.

Common Mistakes When Typing getServerSideProps

• Ignoring the return type: Some developers don’t specify the generic parameter for GetServerSideProps, which means TypeScript can’t check if the returned props match the expected shape.
• Not validating external data: Assuming the API response matches your TypeScript interface without runtime validation can lead to runtime errors. Consider using libraries like zod or io-ts for schema validation.
• Misusing context parameters: Forgetting that context.query values can be string or string[] and not validating accordingly.
• Returning incorrect objects: `getServerSideProps` must return an object with either props, redirect, or notFound. Returning anything else will cause runtime errors.

Performance Considerations

Because `getServerSideProps` runs on every request, it can become a bottleneck if your data fetching is slow or inefficient. Typing doesn’t directly affect performance, but well-typed code encourages better practices:

• Cache responses: If your data doesn’t change often, consider caching it at the server level or using ISR (`getStaticProps` with revalidation) instead.
• Minimize data size: Only fetch and return the data your component actually needs. Over-fetching increases response time and bandwidth.
• Parallelize fetches: If you need multiple API calls, run them in parallel using Promise.all.

Security Considerations

Since `getServerSideProps` runs on the server, you can safely access secrets like API keys or databases without exposing them to the client. However, you still need to be careful:

• Validate inputs: Never trust query parameters or cookies blindly. Always sanitize and validate to avoid injection attacks.
• Handle errors gracefully: Don’t leak sensitive error details in your response. Use proper error handling and return user-friendly messages or redirects.
• Limit data exposure: Only send the minimum necessary data to the client. Avoid sending sensitive information in props.

Comparison: getServerSideProps vs getStaticProps vs API Routes

Method	When to Use	Typing Considerations	Performance	Use Case Example
getServerSideProps	Fetch data on every request; dynamic data based on request	Use GetServerSideProps<Props> for typing; context includes request info	Slower, runs on each request	User dashboard with real-time data
getStaticProps	Fetch data at build time; static content	Use GetStaticProps<Props>; no request context	Fast, served from CDN	Blog posts, marketing pages
API Routes	Serverless functions; custom endpoints	Type request and response objects manually or with helper libs	Depends on function execution time	Form submission, authentication

Interview Tips: Talking About getServerSideProps Typing

• Explain the importance of typing for maintainability and catching bugs early.
• Mention how Next.js provides built-in types like GetServerSideProps and GetServerSidePropsContext.
• Highlight the need to validate external data before trusting it.
• Discuss how typing helps with IDE autocompletion and developer experience.
• Bring up common pitfalls like untyped query parameters or returning incorrect objects.
• If asked about alternatives, compare with getStaticProps and API routes, focusing on use cases and performance.

Summary

Typing `getServerSideProps` is straightforward once you understand the built-in Next.js types. The key is to define your props interface clearly, use GetServerSideProps<Props> to type your function, and validate any external or user-provided data. This approach reduces bugs, improves code clarity, and makes your Next.js apps more maintainable.

In production, I always combine TypeScript types with runtime validation for external data, especially when working with third-party APIs or user input. This combination helps catch issues early and prevents unexpected crashes.

Finally, remember that `getServerSideProps` impacts performance since it runs on every request, so use it judiciously and optimize your data fetching accordingly.