Skill reading | HackIndia

1. Start the App Router app

4 min

Key point

One idea

Start with App Router from day one. In Next.js, routes come from files, and the app folder is where your project will grow.

For this track, your repo must clearly show App Router files. Do not start with an older Pages Router tutorial and try to convert it at 2 am.

What you create

You will create a Next.js app using create-next-app. The current default setup gives you TypeScript, Tailwind CSS, ESLint, App Router, Turbopack, the @/* import alias, and AGENTS.md.

You only need the starter today. Later lessons will add routes, Server and Client Components, server data fetching, and a route handler.

Your to-do

Before you start

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Check that your laptop has Node.js 20.9 or newer.
Use macOS, Windows with WSL, or Linux.
Choose a short project name, like campus-helpdesk or mess-feedback.
Open a terminal in the folder where you keep hackathon projects.

0 of 4 done

Example

Create and run

Use pnpm if you have it. This command creates the app with the default recommended choices, including App Router.

The dev server runs locally. Open the local URL it prints in your browser.

pnpm create next-app@latest campus-helpdesk --yes
cd campus-helpdesk
pnpm dev

2. Map routes with files

4 min

Key point

One rule

In App Router, your URL comes from your files. A folder becomes a route only when it has a page.tsx file inside it.

app/page.tsx is the home route /. app/team/page.tsx becomes /team. app/projects/new/page.tsx becomes /projects/new.

What counts as a route

Next.js uses file-system routing. You do not write a route table for normal pages.

This is useful in hackathons. A judge or recruiter can open your repo and see your app structure quickly.

Example

Starter route map

For a campus hackathon project, keep the first route map small. Add only the pages you can finish and test on a phone.

Here is a simple structure for a student project showcase app.

app/
  layout.tsx
  page.tsx
  about/
    page.tsx
  projects/
    page.tsx
    new/
      page.tsx
  contact/
    page.tsx

Layouts wrap pages

3. Split server and client components

5 min

Key point

One split rule

Keep pages and layouts as Server Components by default. Make a Client Component only when you need clicks, typing, state, effects, or browser APIs like window and localStorage.

This keeps less JavaScript on the judge phone. It also keeps server-only code away from the browser.

Default is server

In the App Router, layouts and pages are Server Components unless you mark them otherwise. So app/page.tsx and app/dashboard/page.tsx can render UI without adding 'use client'.

Server Components are good for reading files, calling a database later, and preparing data before the page reaches the browser. You will use that more in the next lesson.

Your to-do

Choose the side

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

6. Prepare for production

4 min

Key point

Production means real URL

Your project is not ready when it works on localhost. It is ready when a judge can open a public URL on a phone and use the main flow.

For this track, keep your App Router features working: layouts, Server Components, server fetches, and route handlers.

Build before deploy

A production build catches problems that dev mode may hide. Run it before every deployment, especially after adding a route handler or server-side data fetch.

Next.js production scripts should include dev, build, and start. The build step prepares the app. The start step runs the production server locally.

Example

Package scripts

4. Fetch data on the server

4 min

Key point

Main idea

In App Router, pages and layouts are Server Components by default. That means you can fetch data directly in the component before it renders.

Use a route handler only when the browser or another service needs an API. For a normal page read, fetch on the server.

Why server fetch

A hackathon judge does not care where your data comes from. They care that the deployed page opens fast, shows real content, and does not leak secrets.

Server-side fetching helps because your database query, API key, and filtering logic stay on the server. They are not shipped in the client JavaScript bundle.

Your to-do

Choose one data source

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Use a public JSON API if you are still prototyping.
Use your own database or backend if your project already has one.
Keep secret tokens in unprefixed environment variables, not in client code.
Avoid adding 'use client' to the page that fetches the data.

0 of 4 done

Example

Server page fetch

This example creates a projects page that fetches data on the server. The page component is async, then it awaits fetch and renders the result.

Replace the URL with your real API later. The shape of the data must match what you render.

// app/projects/page.tsx
type Project = {
  id: number
  name: string
  city: string
}

async function getProjects() {
  const res = await fetch('https://example.com/api/projects')

  if (!res.ok) {
    throw new Error('Failed to load projects')
  }

  return res.json() as Promise<Project[]>
}

export default async function ProjectsPage() {
  const projects = await getProjects()

  return (
    <main className="p-6">
      <h1 className="text-2xl font-bold">Student projects</h1>
      <ul className="mt-4 space-y-3">
        {projects.map((project) => (
          <li key={project.id} className="rounded border p-3">
            <p className="font-medium">{project.name}</p>
            <p className="text-sm text-gray-600">{project.city}</p>
          </li>
        ))}
      </ul>
    </main>
  )
}

Tip

Ask AI well

You can ask ChatGPT or Gemini to draft the fetch function and TypeScript type. Give it one sample JSON item and the page path.

Check three things in the answer: no 'use client' at the top, the component is async, and errors are handled when the response is not ok.

Common mistake

Common wrong turn

Many older tutorials fetch page data with useEffect and useState. That makes the browser wait, then fetch, then update the page.

For App Router, start with server fetching. Move to a Client Component only when the user must click, type, filter, or use a browser API.

Caching note

Current Next.js docs say fetch requests are not cached by default. A fetch can block rendering until it finishes.

For this lesson, keep it simple. Get the data rendering correctly first. Add caching or streaming later only when your app needs it.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Create one page in app/ that needs real data, such as app/projects/page.tsx.
Make the page component async and fetch data inside it.
Render at least three fields from the returned data.
Confirm the page has no 'use client' directive.
Commit the file so your public repo shows server-side data fetching.

0 of 5 done

5. Add an API route handler

4 min

Key point

One idea

A route handler is a server endpoint made by adding route.ts inside the app folder. Use it when your browser UI, webhook, mobile client, or another service needs to call your app over HTTP.

Do not create an API route for every database read. In App Router, Server Components can fetch data directly on the server.

Where it fits

Your pages use page.tsx. Your layouts use layout.tsx. Your API endpoint uses route.ts.

The folder path becomes the URL. app/api/status/route.ts becomes /api/status. This is file-based routing, but for HTTP methods instead of screens.

Example

Simple GET route

Add this file to your project. It returns JSON that your judge, frontend, or phone browser can open.

// app/api/status/route.ts

export async function GET() {
  return Response.json({
    ok: true,
    app: "HackIndia demo",
    message: "API route is working",
  });
}

Your to-do

Test the route

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Start your dev server if it is not already running.
Open /api/status in your browser.
Check that you see JSON, not a page layout.
Change the message and refresh to confirm the file is connected.
Commit the new app/api/status/route.ts file to your repo.

0 of 5 done

Example

POST for form data

Use POST when the browser sends data to your server. This example accepts a team name for a hackathon project and returns a small response.

This does not save to a database yet. It proves that your app can receive JSON and respond from the server.

// app/api/teams/route.ts

type TeamRequest = {
  teamName?: string;
};

export async function POST(request: Request) {
  const body = (await request.json()) as TeamRequest;

  if (!body.teamName) {
    return Response.json(
      { error: "teamName is required" },
      { status: 400 }
    );
  }

  return Response.json({
    saved: true,
    teamName: body.teamName,
  });
}

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to write a route.ts for your exact use case. Give it your folder path, method, expected request body, and expected response.

Check three things in the answer: it exports GET or POST by name, it uses Request and Response APIs, and it does not put secret keys in client code.

Common mistake

Beginners often fetch their own API route from a Server Component just to read server data. That adds an extra HTTP hop inside the same app.

If only a page needs the data, fetch it directly in the Server Component. If a Client Component, form, webhook, or external app needs an endpoint, use route.ts.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Create app/api/status/route.ts with a GET handler.
Open /api/status locally and confirm JSON appears.
Create app/api/teams/route.ts with a POST handler if your project has forms.
Add a short note in your README: API routes: /api/status and any project-specific endpoint.
Commit and push the route handler files to your public repo.

0 of 5 done

7. Submit the public repo

5 min

Key point

Proof beats claims

Judges and recruiters will not inspect every file deeply. Your repo should make the App Router evidence easy to find in under two minutes.

Your submission must show file-based routes, layouts, Server and Client Components, one server-side data fetch, one route handler, and a deployed URL that works on a phone.

Your to-do

Final repo check

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your public repository in a private browser window.
Confirm the app folder is visible and uses file-based routes with page.tsx and layout.tsx files.
Find the Client Component with 'use client' at the top of the specific interactive file only.
Find the Server Component that fetches data with async and await.
Find the route handler file named route.ts or route.js.
Click the deployed link from your repo and test it on mobile data, not only college Wi-Fi.

0 of 6 done

Example

README proof block

Put a short proof section near the top of README.md. Do not make judges hunt through your project.

Keep it factual. Link to the live app and list the exact files that prove each requirement.

Project: Campus Mess Feedback

Live URL: https://your-deployed-app.example

Built with: Next.js App Router

App Router proof:
- File-based routes: app/page.tsx, app/feedback/page.tsx, app/admin/page.tsx
- Shared layout: app/layout.tsx
- Server Component: app/feedback/page.tsx
- Client Component: app/components/RatingForm.tsx
- Server-side data fetch: app/admin/page.tsx fetches feedback before render
- Route handler: app/api/feedback/route.ts handles POST requests

How to run locally:
- Install dependencies
- Run the dev script
- Open the local URL printed in the terminal

Phone test:
- Tested the deployed URL on Android Chrome using mobile data
- Main pages load
- Feedback form submits
- Admin page renders data

Common mistake

Common weak submission

A weak repo only has a live link and a one-line README. That makes your work look unfinished even if the app runs.

Another common mistake is submitting a localhost screenshot. Judges need a public deployed URL. Test it on a real phone because that is how many hackathon judges will open it.

Tip

Use AI carefully

You can ask ChatGPT, Gemini, or Claude to review your README before submission. Paste your file tree and ask it to check whether each App Router requirement is visible.

Do not blindly accept its answer. Verify the file names yourself. AI may claim a route handler exists when your file is actually named handler.ts instead of route.ts.

Example

AI review prompt

Use a prompt like this after you finish the repo. It helps you catch missing proof before submission.

You are reviewing my Next.js App Router hackathon repo README.
Check if it clearly proves these requirements:
1. File-based routes
2. Layouts
3. Server Components
4. Client Components
5. At least one server-side data fetch
6. At least one route handler
7. Public deployed URL tested on a phone

Here is my README:
[paste README]

Here is my app folder tree:
[paste app folder tree]

Return only:
- Missing proof
- Confusing file names
- README edits I should make

Your to-do

Submit checklist

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Make the repository public before submitting.
Add the deployed URL in the repo description and README.
Add a short App Router proof section with exact file paths.
Remove secrets, test files with private data, and unused API keys from the repo.
Open the submission link from your phone and confirm the live app and repo both load.

0 of 5 done

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Open your README.md and add a proof section.
List the exact files for routes, layout, Client Component, server fetch, and route handler.
Paste your deployed URL near the top of the README.
Test the deployed URL on your phone using mobile data.
Submit the public repo link and live URL on HackIndia.

0 of 5 done

Next.js

1. Start the App Router app

One idea

What you create

Before you start

Create and run

2. Map routes with files

One rule

What counts as a route

Starter route map

Layouts wrap pages

3. Split server and client components

One split rule

Default is server

Choose the side

6. Prepare for production

Production means real URL

Build before deploy

Package scripts

Files to notice

Tiny home edit

Avoid old tutorials

Do this now

Root layout example

Add one route

Page example

Common mistake

Plan before coding

Do this now

Server page, client button

Do not client everything

Use AI carefully

Props must be simple

Do this now

4. Fetch data on the server

Main idea

Why server fetch

Choose one data source

Server page fetch

Ask AI well

Common wrong turn

Caching note

Do this now

5. Add an API route handler

One idea

Where it fits

Simple GET route

Test the route

POST for form data

Use AI carefully

Common mistake

Do this now

Local production check

Pick the right host

Localhost is not proof

Ask AI for checks

Do this now

7. Submit the public repo

Proof beats claims

Final repo check

README proof block

Common weak submission

Use AI carefully

AI review prompt

Submit checklist

Do this now