SEO com NextJS: SSG/ISR, Webhooks do Notion e Deploy Automatizado na Vercel

Entendendo o NextJS: SSG, SSR, CSR e ISR

• SSG (Static Site Generation - Gerão de Site Estático): Páginas são pré-renderizadas no momento do build e servidas como HTML estático.

• SSR (Server-Side Rendering - Renderização do lado do Servidor): O servidor monta o HTML completo a cada requisição e o envia ao navegador.

• CSR (Client-Side Rendering - Renderização do lado do Cliente): O navegador carrega um pacote inicial mínimo e constrói a interface dinamicamente via JavaScript.

• ISR (Incremental Static Regeneration - Regeneração Estática Incremental): Mistura os benefícios do SSG com a capacidade de atualizar páginas específicas sob demanda, sem precisar reconstruir o site inteiro.

Por que SSG é melhor para blogs abertos (público)?

• SEO otimizado: o conteúdo já chega aos motores de busca em HTML pronto para ser indexado.

• Performance superior: como as páginas são pré-renderizadas, a entrega é mais rápida, o que também contribui para melhorar o ranqueamento do buscador (Google por exemplo).

Por que deixar SSG p/ depois da 1ª versão?

Integração com Webhook NotionAPI

1. Um conteúdo é atualizado no Notion.

2. Essa alteração dispara um webhook.

3. O backend recebe esse evento e aciona o SDK da Vercel para realizar um novo deploy.

• O webhook do NotionAPI, que sinaliza mudanças em tempo real.

• O SDK da Vercel, que permite acionar programaticamente o rebuild do site.

Criando endpoint de Webhook no backend NodeJS

app.post('/posts/webhooks/notion', async (req, res) => {
  // Descreva a funcionalidade da rota aqui...
})

Validando segurança dos eventos

app.post(
  '/posts/webhooks/notion',
  async (req, res, next) => {
    try {
      const { body } = req
      const sign = (req.headers['X-Notion-Signature'] ||
        req.headers['x-notion-signature'])

	 if (
        !sign ||
        typeof sign !== 'string' ||
        !verifySignature(
          sign,
          process.env.NOTION_WEBHOOK_TOKEN ?? '',
          JSON.stringify(body),
        )
      )
        return res.status(401).json({ message: 'Unauthorized request' })

      return next()
    } catch (e) {
      // eslint-disable-next-line no-console
      console.error(e)
      return res.status(500).json({ error: 'Internal server error' })
    }
  },
  // Handler de manipulação do evento de deploy
)

import { createHmac, timingSafeEqual } from 'crypto'

export function verifySignature(
  signature: string,
  secret: string,
  bodyString: string,
): boolean {
  const calculatedSignature = `sha256=${createHmac('sha256', secret).update(bodyString).digest('hex')}`

  const isTrustedPayload = timingSafeEqual(
    Buffer.from(calculatedSignature),
    Buffer.from(signature),
  )

  return isTrustedPayload
}

Fluxo de Deploy automatizado com Vercel SDK

Implementação do código de deploy

/* eslint-disable no-console */
import { Vercel } from '@vercel/sdk'

export async function createDeployOnVercel() {
  const vercel = new Vercel({
    bearerToken: process.env.VERCEL_API_TOKEN,
  })

  try {
    const createResponse = await vercel.deployments.createDeployment({
      requestBody: {
        name: process.env.VERCEL_PROJECT_NAME!,
        project: process.env.VERCEL_PROJECT_ID!,
        target: process.env.VERCEL_TARGET!,
        gitSource: {
          type: process.env.VERCEL_SOURCE_TYPE! as any,
          org: process.env.VERCEL_SOURCE_ORG!,
          repo: process.env.VERCEL_SOURCE_REPO!,
          ref: process.env.VERCEL_SOURCE_REF! as any,
        },
      },
    })

    console.log(
      `Deployment created: ID ${createResponse.id} and status ${createResponse.status}`,
    )
  } catch (error) {
    console.error(
      error instanceof Error ? `Error: ${error.message}` : String(error),
    )
  }
}

Conectando os eventos ao fluxo de build

app.post(
  '/posts/webhooks/notion',
  async (req, res, next) => {
    // fluxo de verificação do hash e integridade do evento Notion
  },
  async (_, res) => {
    try {
      createDeployOnVercel()

      return res.status(201).send()
    } catch (e) {
      // eslint-disable-next-line no-console
      console.error(e)
      return res.status(500).json({ error: 'Internal server error' })
    }
  },
)

• O primeiro handler atua como middleware, validando o hash do evento (X-Notion-Signature). Se falhar, a requisição é bloqueada imediatamente.

• O segundo handler só é executado se a validação passar, e sua única responsabilidade é chamar createDeployOnVercel().

• A resposta 201 Created indica ao Notion que o evento foi processado com sucesso.

• O deploy roda de forma assíncrona, ou seja, a API não precisa esperar a conclusão do processo para responder ao Notion.

Construindo o SSG no App NextJS

1. forçar cache das requisições à API (para que o Next considere os dados estáticos no build) e

2. pré-gerar as rotas dinâmicas dos posts com generateStaticParams.

// ./app/src/services/get.post.data.ts
export async function getPostData({ slug }: Request): Promise<Result> {
  const result = await fetch(`${config.api.baseUrl}/post/${slug}`, {
    cache: 'force-cache',
  })

  if (!result.ok) throw new Error('Invalid post slug')

  const { recordMap, properties } = await result.json()

  return { recordMap, properties }
}

// ./app/src/services/get.posts.list.ts
export async function getPostsList() {
  const result = await fetch(`${config.api.baseUrl}/posts`, {
    cache: 'force-cache',
  })

  let posts: Cover[] = []

  if (result.ok) posts = await result.json()

  return posts
}

// ./app/src/app/post/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getPostsList()

  return posts.map(({ slug }) => ({
    slug,
  }))
}

/*
	Para reforçar o comportamento estático e evitar geração
	em runtime de slugs desconhecidos, você pode adicionar:
*/
export const revalidate = false
export const dynamicParams = false

Desafios e soluções encontradas

Problema de múltiplos deploys

1. Reduzindo o número de eventos recebidos

2. Validando a coleção de artigos

app.post(
  '/posts/webhooks/notion',
  async (req, res, next) => {
    // fluxo de verificação do hash e integridade do evento Notion
  },
  async (req, res) => {
    try {
      const { body } = req
      const { type, data } = body

      if (
        type === 'page.properties_updated' &&
        data.parent.data_source_id === process.env.NOTION_COLLECTION_ID
      )
        createDeployOnVercel()

      return res.status(201).send()
    } catch (e) {
      // eslint-disable-next-line no-console
      console.error(e)
      return res.status(500).json({ error: 'Internal server error' })
    }
  },
)

3. Implementando batching com timer

/* eslint-disable no-console */
import { createDeployOnVercel } from '../services/create.deploy.on.vercel'

const DEFAULT_TIME = Number(
  process.env.DEFAULT_TIME_DEPLOY_CLOCK || 5 * 60 * 1000,
)

enum TIMER_STATUS {
  READY,
  SCHEDULED,
}

export function DeployTimer(time = DEFAULT_TIME) {
  let status = TIMER_STATUS.READY
  let timeout: NodeJS.Timeout

  function deploy() {
    if (status === TIMER_STATUS.SCHEDULED) clear()
    status = TIMER_STATUS.SCHEDULED

    timeout = setTimeout(async () => {
      await createDeployOnVercel()
      status = TIMER_STATUS.READY

      console.log('Deploy on Vercel Queued')
    }, time)

    console.log('Deploy on Vercel Scheduled')
  }

  function clear() {
    status = TIMER_STATUS.READY
    clearTimeout(timeout)
  }

  return {
    deploy,
    clear,
  }
}

4. Nova rota com batching aplicado

const timer = DeployTimer()

app.post(
  '/posts/webhooks/notion',
  async (req, res, next) => {
   // fluxo de verificação do hash e integridade do evento Notion
  },
  async (req, res) => {
    try {
      const { body } = req

      const { type, data } = body

      if (
        type === 'page.properties_updated' &&
        data.data_source_id === process.env.NOTION_COLLECTION_ID
      )
        timer.deploy()

      return res.status(201).send()
    } catch (e) {
      // eslint-disable-next-line no-console
      console.error(e)
      return res.status(500).json({ error: 'Internal server error' })
    }
  },
)

1. Filtrar eventos irrelevantes no Notion.

2. Garantir que apenas alterações em artigos do blog disparem rebuilds.

3. Agrupar múltiplas mudanças em um único deploy, reduzindo custos, tempo de build e aumentando a eficiência.

Problema extra: O que fazer quando a instância EC2 trava durante o build?

1. Resolução imediata (quando a instância já travou)

• Acessar o console da AWS.

• Interromper a instância travada.

• Reinicializar a máquina.

2. Prevenção (evitar que o problema ocorra novamente)

• Retirar a responsabilidade da Vercel de rodar builds concorrentes.

• Centralizar o fluxo em um pipeline único no GitHub Actions, escrito em YAML, garantindo que os jobs não rodem simultaneamente.

• Assim, o deploy pode ser serializado, prevenindo sobrecarga e aumentando a confiabilidade.

Roadmap e próximos passos

• Implementação de testes automatizados

• Melhoria de design para refletir um blog mais moderno

• Adicionar scripts de monitoramento de performance do conteúdo

• Utilização de ferramenta de bundle para diminuir o tamanho da aplicação devido ao monorepo

• Refatoração do código para desacoplar e preparar a aplicação para futuras substituições

Conclusão