DEV Community: Sidney Alex

Nuxt 3 Auto-imports: configurando Zod e pasta de Schemas

Sidney Alex — Thu, 05 Oct 2023 00:41:56 +0000

Um dos grandes diferenciais do Nuxt 3 é a capacidade de gerenciar automaticamente as importações baseada em seu sistema de diretórios. Mas nem tudo são flores, e muitas vezes precisamos integrar outras ferramentas que não fazem parte do ecossistema Vue/Nuxt, é o caso do Zod, biblioteca de validação baseada em schemas e nativamente não possui um módulo dedicado para o Nuxt.

Criaremos um módulo interno em uma aplicação Nuxt 3 e configurar a importação automática do Zod e configurar uma pasta chamada schemas (que não é nativamente suportada pelo Nuxt) para importar automaticamente os arquivos dentro dela.

Iniciando projeto

Iniciaremos um novo projeto inserindo o comando abaixo no nosso terminal.

> npx nuxi@latest init meu-app

Instalando dependências

Com a aplicação iniciada, navegamos até a pasta raíz do app e instalar o zod.

> cd meu-app
> npm install zod

Após a instalação, é possível utilizar o Zod e definir schemas, mas é necessário realizar a importação dele em cada uso, similar ao arquivo abaixo.

<script setup lang="ts">
import { z } from "zod";

const NameSchema = z.object({
  name: z.string().min(3).max(10).optional(),
});

NameSchema.parse({ name: "John" });
</script>

<template>
  <div>Hello World</div>
</template>

Perceba que caso eu tome a decisão de isolar o NameSchema em um arquivo na pasta schemas, por exemplo, ainda existirá a necessidade de importar o zod nos arquivos, e importar os schemas da pasta, que não é suportada nativamente pelo Nuxt.

Resolveremos isso criando um módulo.

Escrevendo módulo interno

Módulos no ecossistema do Nuxt é considerado uma forma de simplificar integrações e extender/customizar as funcionalidades do framework, e as importações automáticas fazem parte desse comportamento.

Criaremos um arquivo chamado zod.ts na pasta modules, sendo a pasta definida pelo Nuxt para criação de módulos e que vão ser carregados quando a aplicação iniciar.

Um modulo para adicionar a importação automática do Zod pode ser escrito da seguinte forma:

// modules/zod.ts

import { addImports, defineNuxtModule, logger } from "nuxt/kit";

// definimos o módulo
export default defineNuxtModule({
  meta: {
    // nome do módulo
    name: "zod",
  },
  // função que será executada quando o módulo for carregado
  setup() {
    // carregamos o módulo
    logger.success("Zod internal module loaded");

    // adicionamos o import
    // equivalente a import {z} from "zod";
    addImports({
      name: "z",
      from: "zod",
    });
  },
});

Ao executar a aplicação, podemos ver a mensagem que escrevemos no logger aparecer no terminal:

A partir daqui, o {Z} não precisa ser importado em componentes, páginas, composables, server e etc.

Adicionando pasta `Schemas`

Agora vamos adicionar o auto-import de uma pasta inteira para não existir a necessidade de importar cada schema que vamos escrever.

Modificando o módulo da seguinte forma:

// modules/zod.ts

// importamos o addImportsDir
import { addImports, addImportsDir, defineNuxtModule, logger } from "nuxt/kit";

export default defineNuxtModule({
  meta: {
    name: "zod",
  },
  setup() {
    logger.success("Zod internal module loaded");

    addImports({
      name: "z",
      from: "zod",
    });

    logger.info("Put Zod schemas in 'schemas' folder");

    // Adiciona todos os arquivos da pasta schemas como import
    addImportsDir("schemas");
  },
});

Agora todos os arquivos que tiverem uma exportação na pasta schemas vão ter a importação automática configurada.

Exemplo abaixo:

// schemas/nameSchema.ts

export const NameSchema = z.object({
  name: z.string().min(3).max(10).optional(),
});

Decidi reproduzir o novo NLW Setup da Rocketseat... usando Vue.js

Sidney Alex — Sun, 22 Jan 2023 14:32:05 +0000

A Rocketseat é uma das comunidades referência no ensino de JavaScript no Brasil. No backend eles variam bastante, mas no frontend eles são 100% focados na dupla React+React Native e os metaframeworks que surgem dessas ferramentas. O NLW é um evento que acontece algumas vezes por ano, onde durante uma semana é feito o desenvolvimento de algumas aplicações, sempre um backend, um frontend e uma aplicação mobile.
O Vue.js sempre foi o meu framework de estimação, mesmo utilizando React e Angular no trabalho. Então tomei a decisão acompanhar essa edição do evento, mas adicionando uma camada de complexidade: reproduzir as aplicações utilizando Vue e outras ferramentas disponíveis no ecossistema Vue/Nuxt/unJS.
Além do desafio, é uma oportunidade bastante justa de comparar os frameworks ao nível de código, arquitetura e funcionalidades.

Backend: Substituindo o Fastify pelo Nitro

O backend construído para o desafio recebe e envia dados no formato JSON, então nada que o Nitro não possa fazer. O Nitro é o servidor embutido no Nuxt 3 e que assim como outras ferramentas do unJS, pode ser utilizado isoladamente sem nenhuma outra dependência, como explico nesse post.

A instalação de outras bibliotecas como Prisma, Day.js e Zod segue o mesmo padrão encontrado no evento e em suas respectivas documentações. O que muda ao utilizar o Nitro é o sistema de rotas, baseado em arquivos e a construção das rotas, que utiliza eventos no lugar do clássico (request,response).

As rotas separadas em arquivos ajudam bastante na organização do código e nos obrigam a separar o código específico de cada uma. Abaixo exemplo de uma rota com o Nitro.

//   /routes/day/index.get.ts

import dayjs from "dayjs";
import { z } from "zod";
import { prisma } from "../../utils/prisma";

export default defineEventHandler(async (event) => {
  const getDayParams = z.object({
    date: z.coerce.date(),
  });

  const query = getQuery(event);

  const { date } = getDayParams.parse(query);

  const parsedDate = dayjs(date).startOf("day");

  const weekDay = parsedDate.get("day");

  const possibleHabits = await prisma.habit.findMany({
    where: {
      created_at: {
        lte: date,
      },
      weekDays: {
        some: {
          week_day: weekDay,
        },
      },
    },
  });

  const day = await prisma.day.findUnique({
    where: {
      date: parsedDate.toDate(),
    },
    include: {
      dayHabits: true,
    },
  });

  const completedHabits =
    day?.dayHabits.map((dayHabit) => dayHabit.habit_id) ?? [];

  return { possibleHabits, completedHabits };
});

De forma geral, o backend não é tão diferente. Boa parte da aplicação, principalmente o uso do Prisma, Zod e Day.js é exatamente igual.
Link do repositório completo abaixo:

silvercent011 / nlw-setup-nitro

Tailwind CSS: A configuração que (quase) não mudou.

Por ser um framework do CSS, o Tailwind se torna compatível e visualmente idêntico em todos os frameworks.

O que mudei no tailwind.config.js se resume a adição dos arquivos com extensão .vue e a instalação do plugin oficial @tailwindcss/forms.

// tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./index.html", "./src/**/*.{vue,js,ts,jsx,tsx}"],
  theme: {
    extend: {
      colors: {
        background: "#09090A",
      },
      gridTemplateRows: {
        7: "repeat(7, minmax(0,1fr))",
      },
    },
  },
  plugins: [require("@tailwindcss/forms")],
};

Frontend: A briga começa aqui!

Não detalharei as diferenças básicas entre os frameworks, existem milhares de artigos na web fazendo isso. Deixarei o link do repositório antes de falarmos sobre Nuxt(esse é o tópico surpresa por aqui).

A aplicação web no evento da Rocketseat foi gerada utilizando Vite, sendo incrível já que o Vite é mantido pelo core team do Vue. Significa que os passos para criar o projeto são os mesmos, detalhe para a nova CLI do Vue, baseada no Vite e que está disponível para seleção nas opções do comando yarn create vite

A estrutura de pastas é a mesma do projeto com React, ambos os frameworks usam arquivos de componentes(SFC) em sua arquitetura.

A composição dos SFCs difere, no JSX os componentes são funções ou classes do JavaScript. No Vue o SFC possui separação entre o template, script e estilo. O único obrigatório é o <template>.

/src/App.vue
<template>
  <div class="w-screen h-screen flex justify-center items-center">
    <div class="w-full max-w-5xl px-6 flex flex-col gap-16">
      <Header />
      <SummaryTable />
    </div>
  </div>
</template>

<script setup lang="ts">
import Header from "@/components/Header.vue";
import SummaryTable from "@/components/SummaryTable.vue";
</script>

<style scoped>
</style>

Entrando no componente SummaryTables, vemos algumas diferenças entre as duas ferramentas. A primeira delas é a renderização de listas. No JSX precisamos chamar o método map no objeto ou array que queremos iterar e retornar um novo componente a partir do callback que passamos. No Vue isso é resolvido com o atributo v-for no elemento que queremos iterar.

<template>
    <!-- ... -->
      <div
        v-for="(day, index) in weekDays"
        :key="index"
        class="text-zinc-400 text-xl h-10 w-10 font-bold flex items-center justify-center"
      >
        {{ day }}
      </div>
    <!-- ... -->
</template>

<script setup lang="ts">
// ...
const weekDays = ["D", "S", "T", "Q", "Q", "S", "S"];
// ...
</script>

No quesito renderização de listas, ponto para o Vue. Mas nem sempre ser mais simples significa ser melhor. No mesmo componente, temos outro exemplo onde o React leva a melhor.

<template>
    <!-- ... -->
      <HabitDay
        v-for="date in summaryDates"
        :key="date.toString()"
        :date="date"
        :amount="dayInSummary(date)?.amount"
        :defaultCompleted="dayInSummary(date)?.completed"
      />
    <!-- ... -->
</template>

<script setup lang="ts">
// ...
const summaryDates = generateDatesFromYearBeginning();

// ...
function dayInSummary(date: any) {
  const value = summary.value.find((day) =>
    dayjs(date).isSame(day.date, "day")
  );
  return value;
}
</script>

No JSX cada iterável tem o componente gerado de uma função anônima passado no método map. A função dayInSummary no projeto com React é declarada e executada na função anônima. A solução mais rápida que encontrei foi declarar a função na tag <scrit> e chamar nos valores do HabitDay, com certeza existe uma solução melhor, mas não gastei neurônios aqui. Pela flexibilidade, ponto do React aqui.

Um ponto levantado durante as aulas é o uso do hook useEffect para disparar funções quando o componente é montado. Não é proibido, mas o hook não foi feito para resolver esse problema em específico. Enquanto existem RFCs na comunidade React debatendo isso, no Vue podemos utilizar o composable onMounted para essa finalidade.

 <template>
<!-- ... -->
</template>

<script setup lang="ts">
// ...
const summary = ref<Summary>([]);

onMounted(async () => {
  const data = await api.get("summary").then((response) => response.data);
  summary.value = data;
});
// ...
</script>

Substituindo o Radix pelo HeadlessUI

O Radix infelizmente não possui versão para Vue, mas sem desespero. Podemos substituir componentes como Dialog e Popover tranquilamente com o HeadlessUI.
O Headless possui versões para React e Vue, é mantido pelo time do Tailwind.

Não é 100%, mas resolve o problema. Componentes como Checkbox e Progress podem ser feitos de forma simples utilizando apenas o Vue e Tailwind.

Formulários e Two-Way Data Binding

Aqui o Two-Way Data Binding do Vue ganha destaque simplificando algumas operações. Representado pelo atributo v-model, o Two-Way Data Binding faz quase que automaticamente algumas operações onde precisamos aplicar alguma regra de negócio. O destaque nessa aplicação é no formulário de recorrência de dias, onde o Vue monta o array com os dias da semana selecionados quase automaticamente.

Iteramos os dias da semana, e colocamos o index como valor do checkbox. O v-model vai e manipular o array armazenado em weekDays com o que passamos no atributo value.

/src/components/NewHabitForm.vue
<template>
  <!-- ... -->
  <div class="flex flex-col gap-2 mt-3">
    <div
      class="flex items-center gap-3"
      v-for="(weekDay, index) in availableWeekDays"
      :key="index"
    >
      <div>
        <input
          class="..."
          type="checkbox"
          :value="index"
          v-model="weekDays"
        />
      </div>
      <span class="text-white leading-tight"> {{ weekDay }} </span>
    </div>
  </div>
  <!-- ... -->
</template>

<script setup lang="ts">
// ...
const availableWeekDays = [
  "Domingo",
  "Segunda-Feira",
  "Terça-Feira",
  "Quarta-Feira",
  "Quinta-Feira",
  "Sexta-Feira",
  "Sábado",
];
const weekDays = ref<number[]>([]);
// ...
</script>

Se pontuar tudo, o texto ficará maior do que já está. Quem quiser ver a implementação completa, só abrir o repositório abaixo:

silvercent011 / nlw-setup-vue

nlw-setup-vue

This template should help get you started developing with Vue 3 in Vite.

Recommended IDE Setup

VSCode + Volar (and disable Vetur) + TypeScript Vue Plugin (Volar).

Type Support for `.vue` Imports in TS

TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need TypeScript Vue Plugin (Volar) to make the TypeScript language service aware of .vue types.

If the standalone TypeScript plugin doesn't feel fast enough to you, Volar has also implemented a Take Over Mode that is more performant. You can enable it by the following steps:

Disable the built-in TypeScript Extension
1. Run Extensions: Show Built-in Extensions from VSCode's command palette
2. Find TypeScript and JavaScript Language Features, right click and select Disable (Workspace)
Reload the VSCode window by running Developer: Reload Window from the command palette.

Customize configuration

See Vite…

View on GitHub

Nitro + Vue = Nuxt

O Nitro é o servidor que vem incluído por padrão no Nuxt 3.
Então, em um projeto Nuxt, criei a pasta server e colei a pasta routes e utils do projeto backend. Você não leu errado, apenas copiei e colei a pasta. Troquei o nome de routes para api. Realizei a configuração do Prisma e pronto! API funcionando dentro do Nuxt.

Frontend

O Nuxt 3 possui um sistema automático de importações, então as funções do Vue, tudo que estiver em pastas específicas como components não precisam ser importados, o Nuxt realiza as importações automaticamente.

Tailwind e Headless

Fiz a instalação do módulo oficial do Tailwind para Nuxt e do módulo do HeadlessUI para aproveitar as importações automáticas. Para finalizar copiei o arquivo tailwind.config.js do nosso frontend.

Ao executar o comando dev com o gerenciador de pacotes, o Nuxt inicia o Nitro para backend, Vite para frontend e o módulo do Tailwind habilita uma rota especial que é uma espécie de documentação e exibe modificações que fazemos no arquivo de configurações.

Exemplo da cor de background que está customizada nas configurações do Tailwind.

Copiando as pastas dentro do src do frontend, e instalando as bibliotecas restantes, podemos realizar algumas substituições.

Substituindo o Axios pelos composables nativos do Nuxt 3

O Nuxt 3 possui composables(hooks para quem vem do React) nativos que realizam requisições otimizadas. As rotas que declaramos na pasta server/api são tipadas automaticamente.

A resposta da api também é tipada pelo Nuxt, que suporta Top-level await, então matamos o estado vazio inicial e o composable onMouted de todos os componentes, substituindo apenas por um await na tag <script>.

A implementação completa no repositório abaixo:

silvercent011 / nlw-setup-nuxt

Nuxt 3 Minimal Starter

Look at the Nuxt 3 documentation to learn more.

Setup

Make sure to install the dependencies:

# yarn
yarn install

# npm
npm install

# pnpm
pnpm install

Development Server

Start the development server on http://localhost:3000

npm run dev

Production

Build the application for production:

npm run build

Locally preview production build:

npm run preview

Check out the deployment documentation for more information.

View on GitHub

Até a próxima! 🤓

Inicializando o mongoose no Nitro (a forma fácil, rápida e talvez a única...)

Sidney Alex — Sun, 27 Nov 2022 01:55:09 +0000

Oi! Nem eu esperava gostar tanto de escrever por aqui. No post passado expliquei como criar uma REST API simples utilizando o Nitro e o Prisma combinado ao MongoDB.

Acontece que o Prisma não é o ODM mais famoso do MongoDB no universo JavaScript/Node. A biblioteca mais utilizada (e acredito que vai ser assim por muito tempo) é o mongoose.

Vamos começar com a estrutura padrão do Nitro.

Se você não sabe como chegamos aqui, dá uma olhadinha no post anterior.

Instalando o mongoose

Dentro do projeto, execute o comando a seguir para instalar o mongoose:

npm i mongoose

Instanciando o mongoose

Diferente do Prisma, o mongoose não cria as conexões automaticamente. Precisamos criar uma instancia do mongoose no inicio da nossa aplicação, mas como fazer isso se o Nitro inicia automaticamente e todos os arquivos que criamos são rotas?

Para isso, o Nitro possui um sistema de plugins customizados. Segundo a documentação, cada plugin que escrevemos é executado de forma síncrona na primeira inicialização do servidor, que é o lugar mais adequado para inicializar o mongoose no Nitro.

Vamos criar uma pasta chamada plugins na raiz do nosso projeto, dentro dela criaremos um arquivo chamado mongooseConnect.ts. O nome pode ser qualquer um de sua escolha.

Dentro do arquivo escreveremos o seguinte conteúdo:

//plugins/mongooseConnect.ts

// Importação do mongoose
import mongoose from "mongoose";

// Definição do plugin
export default defineNitroPlugin(async (nitroApp) => {
  try {
    // inicializando a conexão com o mongodb
    await mongoose.connect("SUA URI DE CONEXÃO COM O MONGODB");
    console.log("MongoDB conectado");
  } catch (error) {
    console.error("Conexão com o MongoDB falhou", error);
  }
});

Para que o plugin funcione, precisamos registra-lo no arquivo de configuração do Nitro, o nitro.config.ts. Faremos o registro da seguinte forma:

//nitro.config.ts

import { defineNitroConfig } from "nitropack";

export default defineNitroConfig({
  // registrando o plugin
  plugins: ["./plugins/mongooseConnect.ts"],
});

Com essa configuração, você deve conseguir utilizar 100% do mongoose no seu projeto com Nitro. Até logo 👋👋👋👋👋

Uma simples API REST utilizando Nitro ⚗ + Prisma 🔺 + MongoDB 🍃

Sidney Alex — Sun, 20 Nov 2022 18:40:43 +0000

Ao pesquisar sobre construir APIs ou webservices utilizando JavaScript/Node.js é comum encontrar diversos tutoriais utilizando frameworks (além de guias, utilizando os módulos nativos do Node) como Express ou NestJS, ferramentas sólidas e bastante utilizadas na comunidade. É de se esperar, considerando o tamanho que o ecossistema JavaScript, que não ficaríamos limitados a apenas duas ferramentas, certo?

Recentemente, o desenvolvimento do Nuxt 3 tem chamado bastante a minha atenção, não só por ser o framework fullstack do Vue (quem me conhece pessoalmente, sabe que defendo o Vue com unhas e dentes), mas principalmente pela forma que o time escolheu para desenvolver as bases do framework.

UnJS

O time do Nuxt criou organização, o UnJS, responsável por criar e manter diversos pacotes que são "universais" e agnósticos de qualquer framework e/ou ambiente. Juntos, muitos desses pacotes formam a base do Nuxt 3.

H3 e Nitro

Sendo um framework fullstack, o Nuxt oferece a possibilidade de criar um servidor http dentro do projeto, o H3 é responsável por isso. Quando utilizado isoladamente, o H3 é muito similar ao express, mas no lugar dos callbacks é utilizado um sistema próprio de eventos.

O Nitro, que vamos utilizar nesse tutorial, combina o servidor http do H3 com algumas outras bibliotecas do UnJS que nos dão algumas features interessantes, como autoimports das bibliotecas instaladas e um sistema de rotas baseado em arquivos (como encontramos em frameworks como Next.js ou no próprio Nuxt).

O Nitro é o servidor http que é gerado automaticamente na pasta server de um projeto Nuxt 3.

O que vamos construir hoje?

Criaremos do zero uma API REST de uma biblioteca, gerenciando o CRUD de Livros, Autores e Gêneros.

Utilizaremos o Nitro como servidor HTTP.
Nosso ORM será o Prisma.
O banco de dados será uma instância no MongoDB criada no Atlas.

Como o Prisma suporta diversos bancos de dados relacionais, sinta-se a vontade para utilizar outras opções se preferir.

Criando um projeto Node e instalando o Nitropack

Vamos criar uma pasta, e iniciar um projeto Node.js dentro dela.

mkdir books-nitro-api
cd books-nitro-api
npm init -y

Ainda com o terminal aberto, vamos instalar o nitropack como dependência de desenvolvimento utilizando o comando abaixo.

npm install --dev nitropack

Abrindo a pasta no nosso editor de código, podemos inserir os scripts do nitro no nosso package.json. O resultado deve ser parecido com o código abaixo.

{
  "name": "books-nitro-api",
  "version": "1.0.0",
  "license": "MIT",
  "scripts": {
    "dev": "nitro dev",
    "build": "nitro build"
  },
  "devDependencies": {
    "nitropack": "^1.0.0"
  }
}

O TypeScript é gerenciado de forma automática pelo Nitro.
Vamos criar o arquivo tsconfig.json na raiz do nosso projeto, e adicionar o seguinte conteúdo como indicado na documentação.

{
  "extends": "./.nitro/types/tsconfig.json"
}

As pastas .nitro e .output são geradas automaticamente assim que rodamos o projeto.

Finalizando a etapa de configuração, vamos adicionar o arquivo nitro.config.ts e inserir o conteúdo abaixo que corresponde à função de configuração do Nitro.

import { defineNitroConfig } from 'nitropack'

export default defineNitroConfig({})

Vamos criar a nossa primeira rota, como dito anteriormente, o Nitro possui um sistema baseado em arquivos para definir suas rotas. Na raiz vamos criar a pasta router e criar o arquivo index.ts que vai corresponder a nossa rota / do servidor.

Dentro do arquivo index.ts vamos definir nosso primeiro evento, assim como sua biblioteca base, o H3, o Nitro é baseado em eventos.

// routes/index.ts
export default defineEventHandler((event) => {
  return "<h1>Hello World</h1>";
});

A estrutura de arquivos deve ficar semelhante à imagem abaixo.

Inicie o servidor de desenvolvimento utilizando o comando abaixo:

npm run dev

O terminal deve exibir as URLs para acessar o servidor, como na imagem abaixo:

Observe que as pastas .nitro e .output foram geradas automaticamente.

Ao digitar a URL fornecida no navegador, temos o retorno que escrevemos no arquivo routes/index.ts

MongoDB

Não abordaremos em detalhes sobre a criação de um banco de dados com MongoDB neste tutorial.

Abra uma nova guia, crie uma conta no MongoDB Atlas e volte aqui quando já tiver uma string de conexão com o banco.

...

Já voltou? Seguindo para a instalação do Prisma!

Instalando o Prisma

Vamos utilizar o Prisma como nosso ODM, uma espécie de tradutor entre o banco de dados e a linguagem de programação.

Vamos instalar o Prisma como dependência de desenvolvimento, utilizando o comando abaixo:

npm install prisma --save-dev

Logo em seguida, vamos instanciar os arquivos do Prisma utilizando o comando abaixo:

npx prisma init --datasource-provider mongodb

Você vai perceber que houve mudanças nos arquivos do nosso projeto, o comando anterior criou uma pasta chamada prisma e um arquivo .env que corresponde à configuração de ambiente da aplicação.

A estrutura de arquivos deve parecer com a imagem abaixo:

Dentro do arquivo .env haverá uma propriedade chamada DATABASE_URL, é aqui que vamos colar a string de conexão com o MongoDB, similar ao snippet abaixo:

// .env
DATABASE_URL="mongodb+srv://USERNAME:PASSWORD@HOST:PORT/DATABASE"

Abrindo o arquivo prisma/schema.prisma, temos algumas informações já inseridas automaticamente pelo Prisma, como o client (que vamos instalar nos próximos passos), o banco de dados, MongoDB no nosso caso, e uma url que importa a nossa variável de ambiente que vai conectar a nossa API ao banco de dados na nuvem.

// prisma/schema.prisma

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}

Aqui vamos criar um modelo básico de livro com os campos name, ìsbn e description, além de outros campos relacionados ao banco. Vamos adicionar o seguinte trecho de código:


model Book {
  id          String    @id @default(auto()) @map("_id") @db.ObjectId
  name        String
  isbn        String    @unique
  description String
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt
}

model Book- aqui informamos ao schema que criaremos uma coleção de documentos, em um banco relacional o Prisma cria uma tabela.
id String @id @default(auto()) @map("_id") @db.ObjectId- cada documento do MongoDB possui um id único do tipo String, o que significam as notações com @ no final da linha. Essas notações variam de banco para banco dentro do Prisma.
Declaramos os atributos name, isbn e description do tipo String, atenção para a notação @unique que inserimos no campo isbn, indicando que esse valor não pode se repetir e é único para cada documento.
Os campos createdAt e updatedAt não são obrigatórios, mas é interessante saber quando o registro foi criado e atualizado pela última vez, as notações são padrão do Prisma.
Outras informações relevantes podem ser encontradas na documentação.

Instalando o Prisma Client

O Prisma Client é a parte do Prisma responsável por gerenciar o banco de dados e gerar a tipagem baseada no schema que criamos no passo anterior. Instale a biblioteca com o seguinte comando:

npm install @prisma/client

Após instalar a biblioteca, é hora de gerar as tipagens específicas que o TypeScript do nosso projeto vai utilizar, a cada modificação do schema devemos rodar o comando

npx prisma generate dev

Instanciando cliente do Prisma

Em toda a nossa aplicação, devemos ter apenas um cliente do Prisma gerenciando todas as nossas requisições.

Crie uma pasta utils na raiz do nosso projeto e dentro dela um arquivo prisma.ts com o seguinte conteúdo:

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

export { prisma };

Criando as rotas da API

Baseado em eventos e com o sistema de rotas baseado em arquivos, o Nitro possui uma organização de arquitetura um pouco diferente de outros frameworks.

Dentro da pasta routes crie em seguida as pastas api, e a seguinte estrutura de arquivos:

Observe que o método da nossa requisição http é declarado no arquivo.
Ambos os arquivos vão responder pela mesma URL na API, http://minhapi/api/books, mas um com o método GET e outro com o método POST.
(Saiba mais sobre os métodos HTTP)[https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods]

Iniciando pelo código do método GET:

// routes/api/books.get.ts

import { prisma } from "../../utils/prisma";

export default defineEventHandler(async (event) => {
  const books = await prisma.book.findMany();
  return books;
});

Na primeira linha importamos o cliente do Prisma que instanciamos no passo anterior.
Logo em seguida exportamos por padrão em toda rota do Nitro a função do defineEventHandler do H3, o Nitro vai gerenciar a importação do H3 por padrão, sem precisar declarar explicitamente.
A função defineEventHandler recebe por parâmetro uma função anônima que expõe o evento que tanto falamos desde o início do post e que vai ser mais útil quando comentarmos sobre o método POST.
Como a função anônima que passamos por parâmetro é assíncrona, veja mais sobre assincronismo no JS, definimos uma constante books e esperamos que o nosso cliente do Prisma retorne todos os livros da API através do método findMany().
Por fim, retornamos o resultado para o cliente que está solicitando os dados a nossa API.

// routes/api/books.post.ts

import { prisma } from "../../utils/prisma";

export default defineEventHandler(async (event) => {
  const payload = await readBody(event);

  const newBook = await prisma.book.create({ data: payload });
  return newBook;
});

Seguindo a mesma estrutura padrão do anterior, mas observe que na constante payload eu chamo outro método do H3 e passo o meu evento como parâmetro. Todos os dados da nossa requisição estão guardados dentro do evento. Nesse caso estamos lendo o body que mandamos por requisição com os dados do livro a ser cadastrado.
Na constante newBook utilizamos o método create() do Prisma para inserir um livro no banco de dados, e retornamos ele na linha seguinte.

Então, esse é o tutorial de uma API bem simples utilizando essa stack. Talvez eu volte aqui em outros posts para falar sobre mais detalhes que ficaram de fora desse guia (rotas mais complexas, tratamento de erros, manipulação de eventos, middlewares...), até a próxima 🤓🖖