Table of Contents

1. Introduction
2. Why Modular and Microservice Architectures?
3. Monorepo Setup with Turborepo
4. Structuring Multiple Apps and Shared Packages
5. Decoupling Frontend and Backend Logic
6. Using tRPC for Type-Safe APIs
7. GraphQL as a Universal Interface
8. Direct DB Access in Server Components
9. Sharing Logic and UI Across Services
10. Authentication and Authorization Strategies
11. Deployment Strategies for Multi-App Systems
12. Conclusion

---

1. Introduction

Modern web apps are rarely monoliths. As your codebase grows, modular architecture and microservices help you:

• Keep features isolated
• Enable independent deployments
• Reuse shared components
• Scale teams and systems more efficiently

With Next.js (App Router) and tools like Turborepo, tRPC, GraphQL, and Prisma, you can build a production-grade microservice-oriented fullstack app inside a monorepo.

---

2. Why Modular and Microservice Architectures?

Benefits include:

• Separation of Concerns: Different teams can work on different parts (auth, billing, UI).
• Better CI/CD: Smaller units = faster builds.
• Independent Scaling: Backend services can scale independently from frontend apps.
• Shared Logic and UI: Use shared packages for validation, types, UI components, etc.

---

3. Monorepo Setup with Turborepo

Use Turborepo to manage monorepos efficiently.

npx create-turbo@latest

Directory structure:

apps/
  web/           → Next.js frontend
  admin/         → Another Next.js app
  api/           → Express or custom backend
packages/
  ui/            → Reusable UI components
  config/        → Shared Tailwind config
  utils/         → Shared helpers, zod schemas, types

turbo.json defines the build pipeline per app/package.

---

4. Structuring Multiple Apps and Shared Packages

Apps: Each folder under apps/ is an independently deployable app.

Packages: Shared code lives here. This can include:

• ui (React components, buttons, inputs)
• types (TypeScript interfaces, zod schemas)
• lib (API clients, database helpers)

You can import like so:

import { Button } from '@myorg/ui';
import { userSchema } from '@myorg/types';

Configure tsconfig.json paths and set up project references.

---

5. Decoupling Frontend and Backend Logic

You can decouple by:

• Creating a separate api/ backend app using Express, NestJS, or even another Next.js app
• Using an RPC layer like tRPC or GraphQL
• Making backend functions callable via server components

---

6. Using tRPC for Type-Safe APIs

tRPC lets you create type-safe API layers with zero client/server code duplication.

Setup:

In packages/trpc:

// trpc/router.ts
import { initTRPC } from '@trpc/server';

const t = initTRPC.create();

export const appRouter = t.router({
  greeting: t.procedure.query(() => 'Hello from tRPC!'),
});

export type AppRouter = typeof appRouter;

In frontend (SSR/server components):

// web/app/api/trpc/[trpc].ts
import { appRouter } from '@myorg/trpc';
import { createNextApiHandler } from '@trpc/server/adapters/next';

export default createNextApiHandler({ router: appRouter });

Client-side usage:

const { data } = trpc.greeting.useQuery();

---

7. GraphQL as a Universal Interface

For more flexibility and API federation, you can opt for GraphQL:

• Use Apollo Server in your backend.
• Use urql or Apollo Client in your frontend.
• Design a modular schema with multiple resolvers for user, product, orders, etc.

Example:

query {
  user(id: "1") {
    name
    email
  }
}

GraphQL also supports batching, subscriptions, and granular access control.

---

8. Direct DB Access in Server Components

You can skip the API altogether in some cases and access the database directly in server components.

With Prisma:

// app/page.tsx (server component)
import { db } from '@myorg/db';

export default async function Home() {
  const users = await db.user.findMany();
  return <UserList users={users} />;
}

This is performant and avoids unnecessary API calls — especially useful for internal tools and admin panels.

---

9. Sharing Logic and UI Across Services

Use packages like:

• @myorg/ui: Button, Modal, Input
• @myorg/validators: Shared zod schemas
• @myorg/db: Prisma client and models
• @myorg/auth: Shared auth logic (e.g., JWT verification)

Enable TypeScript project references so everything compiles properly.

---

10. Authentication and Authorization Strategies

Each app can share auth logic from @myorg/auth, which includes:

• JWT signing/verification
• Role-based access checks
• Middleware or higher-order components for route protection

You can even move common logic to server-only functions in shared packages.

---

11. Deployment Strategies for Multi-App Systems

Options:

• Vercel: Best for deploying multiple Next.js apps.
• Railway / Render: Great for deploying backend services.
• Docker Compose or Kubernetes: For advanced infra or self-hosted setups.
• Turborepo Remote Caching: Speeds up builds across CI/CD pipelines.

Each app can be deployed independently with its own CI pipeline.

---

12. Conclusion

Building modular fullstack apps and microservices with Next.js is no longer complicated. With App Router, server components, tRPC, GraphQL, and Prisma, you can decouple layers while keeping DX high and performance tight.

A solid monorepo setup ensures scalable development across multiple teams, apps, and services — without duplicating code.

Table of Contents

1. Introduction
2. Why Internationalization Matters
3. Built-in i18n Support in Next.js
4. Step-by-Step Setup for i18n in App Router
5. Routing and Locale Detection
6. Handling Translations with next-intl
7. Dynamic Locale Loading
8. Nested Layouts and Localized Content
9. SEO Best Practices for i18n
10. Handling Forms, Errors, and Dates in Locales
11. Tips for Real-World Multilingual Projects
12. Conclusion

---

1. Introduction

Internationalization (i18n) is crucial for applications with a global user base. With Next.js App Router, i18n capabilities are more seamless and powerful, allowing for:

• Per-locale routing (e.g., /en, /fr, /de)
• Dynamic translation loading
• Localized content components
• SEO enhancements with localized metadata

In this guide, we’ll walk through a practical setup and cover how to build a robust multilingual app.

---

2. Why Internationalization Matters

Here are some key reasons to invest in i18n:

• User experience: Visitors are more likely to engage with content in their native language.
• SEO: Localized URLs and meta tags help rank content better in regional search engines.
• Market reach: Expand your app’s reach across geographies.

---

3. Built-in i18n Support in Next.js

Next.js offers built-in i18n support in the configuration via next.config.js:

// next.config.js
module.exports = {
  i18n: {
    locales: ['en', 'fr', 'de'],
    defaultLocale: 'en',
    localeDetection: true,
  },
};

This does not handle translations — it only provides locale-based routing and detection. For managing translations, we’ll use the next-intl package.

---

4. Step-by-Step Setup for i18n in App Router

1. Install Dependencies

npm install next-intl

2. Set Up the File Structure

app/
  [locale]/
    layout.tsx
    page.tsx
  i18n/
    en.json
    fr.json
    de.json

3. Create Your Locale Files

app/i18n/en.json

{
  "greeting": "Hello",
  "login": "Login",
  "welcome": "Welcome to our app!"
}

Repeat for fr.json, de.json, etc.

---

5. Routing and Locale Detection

With the App Router, you can use dynamic segments to scope content per locale:

// app/[locale]/layout.tsx
import { NextIntlClientProvider } from 'next-intl';
import { notFound } from 'next/navigation';

export default async function LocaleLayout({ children, params: { locale } }) {
  let messages;
  try {
    messages = (await import(`../../i18n/${locale}.json`)).default;
  } catch (error) {
    notFound();
  }

  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider locale={locale} messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

And use localized URLs like:

• /en
• /fr
• /de

---

6. Handling Translations with next-intl

To use a translation string:

// app/[locale]/page.tsx
'use client';

import { useTranslations } from 'next-intl';

export default function HomePage() {
  const t = useTranslations();

  return <h1>{t('welcome')}</h1>;
}

You get full type-safety and fallback handling with next-intl.

---

7. Dynamic Locale Loading

The locale-specific layout already loads the necessary JSON dynamically using:

await import(`../../i18n/${locale}.json`);

This makes the app scalable and optimized for only loading relevant translation payloads.

You can extend this logic to also load:

• Date formatting rules
• Time zone preferences
• Pluralization rules

---

8. Nested Layouts and Localized Content

Since layouts can be nested per route, you can have a consistent layout while swapping out translated content:

// app/[locale]/dashboard/page.tsx
'use client';

import { useTranslations } from 'next-intl';

export default function Dashboard() {
  const t = useTranslations('dashboard');

  return <h2>{t('title')}</h2>;
}

Your translation file:

{
  "dashboard": {
    "title": "Your Dashboard"
  }
}

---

9. SEO Best Practices for i18n

Make sure to update:

1. <html lang="..."> dynamically:

Done in the layout with:

<html lang={locale}>

2. Use the Metadata API to localize meta tags:

// app/[locale]/page.tsx
export async function generateMetadata({ params }) {
  const messages = (await import(`../../i18n/${params.locale}.json`)).default;
  return {
    title: messages.meta.title,
    description: messages.meta.description
  };
}

3. Use <link rel="alternate" hreflang="..."> for alternate locales.

This helps Google understand which page is for which language.

---

10. Handling Forms, Errors, and Dates in Locales

Use Intl.DateTimeFormat for date/time formatting:

const formattedDate = new Intl.DateTimeFormat(locale, {
  dateStyle: 'long'
}).format(new Date());

Translate error messages, buttons, and form placeholders by using structured keys:

{
  "form": {
    "username": "Username",
    "password": "Password",
    "submit": "Submit",
    "errors": {
      "required": "This field is required",
      "invalid": "Invalid value"
    }
  }
}

---

11. Tips for Real-World Multilingual Projects

• Use consistent translation keys with nested objects.
• Maintain one master language file and extract others from it using tools like i18next-parser.
• Add fallbacks for missing translations.
• Use static analysis or linters to detect untranslated keys.
• Centralize translation logic in a utility or wrapper if needed.

---

12. Conclusion

Internationalization with Next.js and the App Router is powerful, flexible, and scalable. With the help of next-intl and dynamic routing, you can deliver localized experiences across the world — with full SEO benefits and optimal performance.

Multilingual support isn’t just a “nice-to-have” anymore. It’s a crucial step for user growth, global trust, and long-term success.

Table of Contents

1. Introduction
2. API Architectures: REST vs GraphQL
3. Where APIs Live in Next.js App Router
4. Understanding Server vs Edge Runtime for APIs
5. Structuring REST APIs in Next.js
6. Creating Typed REST API Handlers with TypeScript
7. Using Middleware in REST APIs
8. Introduction to GraphQL in Next.js
9. Setting Up Apollo Server in App Router
10. Integrating URQL with React Clients
11. Choosing Between REST and GraphQL
12. Best Practices for Scalable APIs in Next.js
13. Conclusion

---

1. Introduction

Next.js is not just a frontend framework. With App Router and React Server Components, it can power robust, scalable backends — including both RESTful APIs and GraphQL.

In this module, we explore:

• How to structure APIs in the App Router.
• The differences between REST and GraphQL in the context of modern frontend-heavy apps.
• The tradeoffs and integrations using Apollo, URQL, and native handlers.

---

2. API Architectures: REST vs GraphQL

Feature	REST	GraphQL
Data fetching	Multiple endpoints	Single endpoint
Flexibility	Rigid, defined by server	Client controls query shape
Versioning	Often required	Avoided due to flexible schema
Over/Under-fetching	Common	Solved via query specificity
Tooling	Native browser tools, Postman	GraphiQL, Apollo DevTools

You can use either — or both — in your Next.js app depending on requirements.

---

3. Where APIs Live in Next.js App Router

With the App Router, APIs are usually created in the special app/api directory.

Example structure:

app/
 └── api/
      └── users/
           ├── route.ts
      └── auth/
           ├── login/
                ├── route.ts

Each route.ts file exports a handler for the HTTP method (GET, POST, etc).

---

4. Understanding Server vs Edge Runtime for APIs

In App Router, routes can be configured to run on:

• Default (Node.js) – More powerful, supports native libraries.
• Edge Runtime – Faster cold starts, minimal latency, ideal for auth or analytics APIs.

You can set it with a directive:

export const runtime = 'edge'; // or 'nodejs'

Use Edge for lightweight operations and Node.js for DB-heavy ones.

---

5. Structuring REST APIs in Next.js

Create a RESTful endpoint in app/api/users/route.ts:

// app/api/users/route.ts

import { NextRequest, NextResponse } from 'next/server';

export async function GET(req: NextRequest) {
  const users = await fetchUsersFromDB();
  return NextResponse.json(users);
}

export async function POST(req: NextRequest) {
  const body = await req.json();
  const user = await createUser(body);
  return NextResponse.json(user, { status: 201 });
}

This mimics classic RESTful semantics:

• GET /api/users – fetch users
• POST /api/users – create user

---

6. Creating Typed REST API Handlers with TypeScript

Typing request/response formats improves API maintainability.

type CreateUserInput = {
  name: string;
  email: string;
};

export async function POST(req: NextRequest) {
  const body: CreateUserInput = await req.json();
  const user = await createUser(body);
  return NextResponse.json(user);
}

Use Zod or Yup for runtime validation.

---

7. Using Middleware in REST APIs

Middleware is useful for:

• Authentication
• Logging
• CORS handling

Example of a basic auth middleware:

// middleware.ts

import { NextRequest, NextResponse } from 'next/server';

export function middleware(req: NextRequest) {
  const token = req.cookies.get('token');
  if (!token) {
    return NextResponse.redirect(new URL('/login', req.url));
  }
  return NextResponse.next();
}

Apply middleware selectively with a matcher.

---

8. Introduction to GraphQL in Next.js

GraphQL is an alternative API paradigm where clients ask for exactly the data they need.

To use GraphQL in Next.js, install a server like Apollo:

npm install @apollo/server graphql

---

9. Setting Up Apollo Server in App Router

Create an Apollo server handler:

// app/api/graphql/route.ts

import { startServerAndCreateNextHandler } from '@as-integrations/next';
import { ApolloServer } from '@apollo/server';
import { NextRequest } from 'next/server';

const typeDefs = `
  type User {
    id: ID!
    name: String!
  }

  type Query {
    users: [User!]!
  }
`;

const resolvers = {
  Query: {
    users: () => [{ id: 1, name: 'Alice' }],
  },
};

const server = new ApolloServer({ typeDefs, resolvers });

const handler = startServerAndCreateNextHandler<NextRequest>(server);

export { handler as GET, handler as POST };

This sets up /api/graphql as a single GraphQL endpoint.

---

10. Integrating URQL with React Clients

URQL is a lightweight GraphQL client alternative to Apollo Client.

npm install urql graphql

Then create a client and wrap your app:

// providers/UrqlProvider.tsx

import { createClient, Provider } from 'urql';

const client = createClient({
  url: '/api/graphql',
});

export const UrqlProvider = ({ children }) => (
  <Provider value={client}>{children}</Provider>
);

Now, you can use the useQuery hook to fetch data.

---

11. Choosing Between REST and GraphQL

Use Case	Prefer REST	Prefer GraphQL
Simple CRUD APIs	✅ Yes	❌ Overkill
Highly nested or customizable UI	❌ Verbose	✅ Query tailoring
Browser caching	✅ REST friendly	Needs manual setup
Real-time updates	❌ Extra config	✅ Subscriptions supported

Hybrid architectures using REST for auth and GraphQL for complex queries are common.

---

12. Best Practices for Scalable APIs in Next.js

• Use App Router with app/api for serverless APIs.
• Choose Node.js runtime for DB-heavy ops, Edge for lightweight logic.
• Use typed inputs and outputs (Zod, TypeScript interfaces).
• Authenticate with middleware or session tokens.
• Use GraphQL only when needed; it introduces schema and tooling overhead.
• For GraphQL, prefer lightweight clients (URQL) unless caching and dev tools are critical.

---

13. Conclusion

Next.js offers a flexible, scalable platform for building full-stack applications — including modern APIs. Whether you prefer traditional REST endpoints or opt for GraphQL flexibility, you can implement them efficiently using App Router and server capabilities.

By understanding runtime environments, API structure, and tooling, you’ll be equipped to build scalable, secure, and performant backends directly within your React-powered Next.js app.